[架构之路-253]:目标系统 - 设计方法 - 软件工程 - 软件设计 - 结构化设计的主要评估指标:高内聚(模块内部)、低耦合(模块之间)的含义

目录

前言:

一、软件工程中的软件设计种类:根据宏观到微观分

(1)软件架构设计(层次划分、模块划分、职责分工):

(2)软件高层设计、概要设计(功能模块的接口与协作细节):

(3)软件详细设计(模块内具体实现方式):

二、软件设计的性能指标:高内聚、低耦合分类

2.1 概述

2.2 内聚类型(模块内部):高内聚

2.3 耦合类型(模块之间):低耦合

参考:


前言:

软件设计按照阶段分为:架构设计、高层设计/概要设计、详细设计。结构化设计是软件设计的基础,高内聚、低耦合是评估软件设计非常重要的指标。在开始软件设计之前,我们先讨论一下这个主题。

一、软件工程中的软件设计种类:根据宏观到微观分

软件架构设计、软件高层设计和软件详细设计是软件开发中三个重要的设计层次,它们各自关注不同的设计方面,如下所述:

(1)软件架构设计(层次划分、模块划分、职责分工):

确定软件系统的整体结构和组织方式,包括系统的分层、模块划分、框架选择等。系统架构设计关注系统的稳定性、可靠性和可扩展性,以及系统各个组成部分之间的交互和接口。软件架构设计是从系统整体级别出发,通过对系统的组成部分、各部分之间的关系及其所承担的功能等进行梳理和设计,确定系统总体的结构风格、包括框架和组件的分配、接口、数据流动等。软件架构设计的目的是为整个系统提供一个坚实、可靠、高效、稳定和可维护的基础,需要考虑因素包括系统的可用性、可伸缩性、可维护性、可安全性等。关注整体的非功能性需求!!!

(2)软件高层设计、概要设计(功能模块的接口与协作细节):

软件高层设计是在软件架构设计的基础上进行的,它关注的是系统中各个模块和组件的功能细节和交互方式,确定系统各个模块之间的接口方式和合理的协作关系,从而实现系统的预期功能。由于高层设计服务于架构设计,其需要考虑到诸如结构合理、功能完备,以及后期的扩展和调整等目标。关注接口定义,与编程语言无关!!!

(3)软件详细设计(模块内具体实现方式):

软件详细设计是在软件高层设计的基础上进一步细化,关注的是每个模块和组件的实现和具体实现方式,包括数据结构、算法、代码实现等方面的细节问题,其目的是为软件开发的人员提供具有可行性和可实现性的详细设计方案。详细设计涉及到诸如如何编写代码、如何测试代码、如何实现功能等具体实现问题,其层次较为具体化详细设计直接指导编码实现!与具体的编程语言相关!!!

因此,软件架构设计、软件高层设计和软件详细设计在软件开发的不同阶段发挥着至关重要的作用。一个好的设计方案可以有效地解决软件开发中的复杂性和不确定性,并提高软件的可靠性、可维护性和可扩展性。

二、软件设计的性能指标:高内聚、低耦合分类

2.1 概述

高内聚和低耦合是面向对象设计中的两个重要原则,它们分别指对象内部的功能关系和对象之间的关系。

(1)高内聚:模块内部

高内聚是指一个对象或一个模块内部的各个元素(属性、方法)之间的联系越紧密,协同工作的完成度越高,这个对象或模块的内聚性就越高。

高内聚的设计方法能够带来以下好处:

  • 提高了对象或模块的可读性、可维护性和可重用性,因为每个元素都具有独立的功能且与对象或模块的整体功能相关;
  • 降低了系统中出现错误的概率,因为缺少的元素会影响到整个对象或模块的功能。

(2)低耦合:模块之间

低耦合是指对象或模块之间的耦合度越低,它们之间的关系越少、越简单,这个对象或模块的耦合性就越低。

低耦合的设计方法能够带来以下好处:

  • 提高了系统的模块化程度,各个对象或模块之间相互独立,便于分工协作和并行开发;
  • 降低了系统中出现错误的概率,因为更改一个对象或模块不会影响到其他对象或模块,减少了错误蔓延的风险。

在面向对象设计中,高内聚和低耦合是非常重要的原则,它们能够帮助设计出更加稳定、可靠、可维护和可扩展的软件系统。其中,高内聚和低耦合被认为是相辅相成的原则,一个对象或模块内部高内聚同时和其他对象或模块之间低耦合是最优的设计方法。

如下是:高内聚、低耦合 与 低内聚、高耦合的比较:

内聚(Cohesion)和耦合(Coupling)是软件设计中两个极其重要的概念,它们都是衡量软件模块质量的重要标准,且密切相关。

内聚是指一个模块内部元素(属性、方法)之间相互联系的程度,即判断一个模块内的元素是否紧密相关的能力。如果一个模块内的元素彼此关联紧密,相互依赖程度高,那么它就具有高内聚性。高内聚表示模块内的元素能够很好地协同工作,以完成共同的任务,能够提高模块的可读性、维护性和可重用性。

耦合是指两个模块之间的相互依赖程度。例如,一些模块之间需要互相调用,传递数据或共享状态。如果两个模块依赖紧密,那么它们就具有高耦合性。高耦合表示两个模块之间可能难以独立变更和测试,会影响到整个系统的可维护性和可扩展性,应该尽量避免高耦合的设计。

因此,内聚和耦合都是衡量软件模块质量的重要指标,高内聚和低耦合的设计有利于提高软件系统的质量和可维护性。在设计软件时,需要尽量保证模块内部具有高内聚,模块之间具有低耦合。这可以通过遵循设计原则(如单一职责原则、接口分离原则、依赖倒置原则等)以及使用设计模式等方法实现。

2.2 内聚类型(模块内部):高内聚

内聚(Cohesion)是软件设计中一个重要的概念,指的是模块或组件内部元素相互关联程度的度量。
内聚性高意味着模块内部的元素彼此相关联共同完成一个明确的功能或任务,而内聚性低则表示模块内部的元素关联性较弱,功能不够集中。

根据元素之间的关联程度不同,内聚性可分为以下几种类型:

  1. 功能内聚(Functional Cohesion)- 业务目标一致模块内的元素共同完成一个明确的功能或任务,各个元素之间相关性紧密,协同工作完成特定的功能。例如,一个计算器模块包括加法、减法、乘法和除法等函数,这些函数在功能上紧密相关,代表了功能内聚。

  2. 顺序内聚(Sequential Cohesion)- 业务步骤相邻:模块内的元素按照一定的步骤或顺序进行操作,前一个元素的输出作为后一个元素的输入,形成一个操作序列。例如,一个文件处理模块包括打开文件、读取文件内容、处理数据和保存结果等步骤,这些步骤由于其操作顺序而形成顺序内聚。

  3. 通信内聚(Communicational Cohesion)- 信息传递相邻:模块内的元素之间通过共享数据进行通信,它们共同处理相关的数据。例如,一个邮件发送模块包括输入收件人、输入邮件内容、验证发送权限和发送邮件等元素,这些元素通过共享邮件内容进行通信,代表了通信内聚。

  4. 过程/函数内聚(Procedural Cohesion)- 函数功能相似:模块内的元素执行相似的操作,并且在同一个流程或算法中相关联。例如,一个排序模块包括选择排序、冒泡排序和快速排序等函数,这些函数在相关算法的上下文中执行相似的操作,代表了过程内聚。

  5. 数据内聚(Data Cohesion)-- 数据访问相邻或共享:模块内的元素同一数据或数据结构进行操作,它们共同对该数据进行处理。例如,一个学生信息管理模块包括添加学生信息、修改学生信息和删除学生信息等操作,这些操作都是围绕学生信息数据进行的,代表了数据内聚。

  6. 时间内聚(Temporal Cohesion)- 代码执行时间相邻:模块内的元素在同一时间段内执行,并且需要在同一时间段进行调用。例如,一个报告生成模块包括收集数据、处理数据和生成报告等操作,这些操作需要在同一时间段内执行,代表了时间内聚。

  7. 逻辑内聚:逻辑内聚是高内聚的一种形式,指的是在一个模块或对象内部,各个元素(属性、方法)按照其功能逻辑上相关的程度进行组织和协作。

    具有逻辑内聚的模块或对象,其内部的元素之间存在着紧密的功能联系,彼此协同工作以完成共同的任务。

  8. 偶然内聚:偶然内聚是指在一个模块或对象内部的各个元素(属性、方法)之间缺乏明确的功能关联或逻辑联系的情况。这种内聚类型是适用于一些临时性或无明确功能划分的模块或对象

    具有偶然内聚的模块或对象往往由于一些历史原因、设计折衷或外部要求等因素而形成,它们内部的元素可能缺乏明确的关联,功能之间可能相互独立或者无关。

    偶然内聚的情况下,模块或对象内部的元素之间可能杂乱无章,难以理解和维护

不同类型的内聚都对软件设计和开发有不同的影响,高内聚是设计的目标,因为高内聚度通常意味着模块的功能清晰,易于理解、维护和测试。设计时需要根据具体需求和设计目标选择合适的内聚类型。

2.3 耦合类型(模块之间):低耦合

耦合(Coupling)是软件设计中描述模块或组件之间相互依赖程度的概念。

耦合度高表示模块之间的相互依赖程度强,耦合度低表示模块之间的相互依赖程度弱。根据模块之间的相互依赖性不同,耦合度可分为以下几种类型:

  1. 无耦合(No Coupling):模块之间没有直接的相互依赖关系,彼此独立存在,并且不共享数据或信息这是理想的耦合类型,但在实际设计中很难完全实现。因为,模块与外界没有交换就成了孤岛。

  2. 数据耦合(Data Coupling):模块之间通过共享数据进行通信,一个模块将数据传递给另一个模块。这种耦合方式通常是通过参数传递来实现的。模块之间只有数据和信息传递,没有业务逻辑的耦合。这是最理想的模块间低耦合的情况

  3. 标记耦合(Stamp Coupling):模块之间通过标记或标识进行通信,一个模块将标记传递给另一个模块,接收方根据标记来识别并处理相应的操作。这种耦合方式通常需要模块之间有共同的标记定义。

  4. 控制耦合(Control Coupling):一个模块直接控制另一个模块的执行流程,通常通过调用另一个模块的方法或函数来实现。这种耦合方式通常需要模块之间有相互调用的关系。

  5. 外部耦合(External Coupling):模块之间通过共享外部实体(如文件、数据库、网络等)进行通信,一个模块通过读取或写入外部实体来与另一个模块进行交互。

  6. 公共耦合(Common Coupling):多个模块共享同一个全局数据或全局变量,它们可能同时读取或同时写入该全局数据。这种耦合方式容易导致模块之间的竞争和潜在的冲突。

  7. 内容耦合(Content Coupling):一个模块直接访问另一个模块的内部数据或内部实现细节,这种耦合方式是最强的,也是应尽量避免的。

降低耦合性是良好软件设计的目标之一。高内聚和低耦合度有助于提高软件的可维护性、可重用性和可测试性。在设计时,应尽量选择低耦合度的设计模式和技术,以减少模块之间的相互依赖,使各个模块能够独立变更和演化。

备注:

模块间耦合无法通过两种方式发生耦合关系:

  • 数据
  • 逻辑

参考:

[架构之路-252]:目标系统 - 设计方法 - 软件工程 - 软件设计 - 分析VS设计、设计层次(架构、高层、详细); 界面设计、结构化设计(高内聚低耦合)和面向对象设计(23种设计模式)-CSDN博客

[架构之路-183]-《软考-系统分析师》-13-系统设计 - 高内聚低耦合详解、图解以及技术手段-CSDN博客

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
推荐,资料太大存放在网盘中,需要可下载观看。含教材。 第一部分 考试简介 1.1 考试大纲要求 1.2 考试科目介绍 第二部分 信息系统基础 2.1 信息系统工程总体规划 2.2 政府信息化与电子政务 2.3 企业信息化与电子商务 2.4 信息资源管理 2.5 信息化的标准、法律和规定 第三部分 系统开始基础 3.1 系统规划 3.2 软件开发方法 3.3 需求工程 3.4 软件系统建模 3.5 系统设计 3.6 测试与评审 3.7 软件开发环境与工具 3.8 系统运行与评价 第四部分 操作系统 4.1进程管理 4.2存储管理 4.3文件管理 4.4作业管理 4.5设备管理 第五部分 数据库系统 5.1数据库模式 5.2数据库完整性约束 5.3并发控制 5.4数据库设计 5.4.1数据库设计阶段 5.4.2ER模型 5.5数据库安全 5.6备份与恢复技术 5.7分布式数据库 5.8数据仓库 5.9数据挖掘 第六部分 计算机网络 6.1开放系统互连参考模型 6.2 TCP/IP协议族 6.3网络规划与设计 6.4计算机网络分类 6.5网络接入技术 6.6网络存储技术 6.7虚拟局域网(VLAN) 第七部分 软件架构设计 7.1 软件架构的概念 7.2 软件架构风格 7.3 面向服务的架构 7.4 特定领域软件架构 7.5 基于架构的软件开发方法 7.6 软件架构评估 7.7 软件产品线 第八部分 基于构件的开发 8.1 中间件技术 8.1.1 中间件的概念 8.1.2 主要的中间件 8.2 典型应用架构 8.3 企业应用集成 第九部分 应用数学 9.1 概率统计应用 9.2 图论应用 9.3 组合分析 9.4 算法的选择与应用 9.5 运筹方法 9.6 数学建模 第十部分 系统安全性与保密性设计 10.1安全与保密基础技术 10.2网络安全 10.3安全体系结构 10.3.1OSI安全模型 10.3.2MIS+S、S-MIS、S2-MIS 10.4安全审计 10.5安全策略 10.5.1核心 - 七定 10.5.2安全策略设计原则 第十一部分 系统配置与性能评价 11.1系统故障模型 11.2系统配置方法 11.3可靠性分析与可靠度计算 11.4性能评价方法 11.5软件容错 第十二部分 知识产权与标准化 12.1知识产权 12.1.1保护期限 12.1.2知识产权人确定 12.1.3侵权判断 12.1.4标准的分类 12.2标准化 12.2.1标准的分类 12.2.2标准类型的识别 第十三部分 多媒体基础知识 13.1多媒体技术基本概念 13.1.1音频相关概念 13.1.2图像相关概念 13.1.3媒体的种类 13.2多媒体相关计算问题 13.2.1图像容量计算 13.2.2音频容量计算 13.2.3视频容量计算 13.3常见多媒体标准 13.4数据压缩技术 13.4.1数据压缩基础 13.4.2有损压缩与无损压缩 第十四部分 嵌入式系统 14.1 嵌入式系统的特点 14.2 嵌入式系统的基本架构 14.3 嵌入式系统网络 14.4 嵌入式系统数据库 14.5 实时任务调度和多任务设计 14.5.1 调度算法分类 14.5.2 单调执行速率调度法 14.5.3 时间轮转调度 14.5.4 最早截止时间优先调度算法 14.5.5 优先级反转 14.6 中断处理和异常处理 14.7 嵌入式系统开发设计 14.7.1 交叉开发环境 14.7.2 开发过程 14.7.3 调试方法 第十五部分 开发管理 15.1 范围管理 15.2 时间管理 15.3 成本管理 15.4 文档管理 15.4.1 软件文档管理指南 15.4.2 计算机软件文档编制规范 15.5 软件配置管理 15.6 软件质量管理 15.6.1 质量管理的概念 15.6.2 质量模型 15.6.3 质量管理过程 15.6.4 质量保证与质量控制 15.7 风险管理 15.8 软件过程改进 15.8.1 CMM 15.8.2 CMMI 15.8.3 ISO/IEC 15504 15.8.4 SJ/T 11234-2001 第十六部分 系统架构设计案例分析 16.1 考点分析 16.2 如何解答试题 16.3 试题解答实例 16.3.1 质量属性与软件架构策略 16.3.2 数据流图与流程图 16.3.3 嵌入式系统设计 16.3.4 软件架构风格的选择 16.3.4 信息系统安全设计 第十七部分 系统架构设计论文 17.1 考点分析 17.2 做好准备工作 17.3 论文写作格式 17.4 如何解答试题 17.5 如何写好摘要 17.6 如何写好正文 17.7 常见问题及解决办法 17.8 论文评分标
范围:CPU上可以识别的代码和数据。全部的代码总和。 要求:从定义开始的设计。完整性,彻底地定义从无开始的整个设计。这是因为软件之软,也是因为硬件平台的多样性和特殊性。 完整把握,从头设计是第一原则。因为软件世界自己并不能统一,还有继续分化的趋势。没有根本一致的基础可能是软件的本性。退回到一无所有是处理软件问题的根本。 在这样的视野下,操作系统只是一个部分,一个模块,不同的操作系统任你选择;语言的选择是运行环境的选择(每种语言有每种语言的运行时布局);所谓框架只是“类库+运行环境”的一种构造。 没有对其负载能力、操作强度进行评估前,这些东西(操作系统、语言、框架)还都不能纳入设计规范。 性能:运行过程的收敛(长时间运行的均态)。操作强度设计(串行处理速度),负载能力设计(并发处理的量)。可靠性设计。 软件问题的3个方面: 1、硬件,软件的操作对象和运行软件的数字系统(CPU系统和数字加速硬件) 2、交互操作(界面),专业界面设计 3、软件调度性能,实时的自动化过程(设备控制和自动测量)和用户交互过程(请求服务过程和干预过程;本地交互和远程交互),程控和网络访问的调度(服务器)。 软件项目的3个部分:(把3个阶段由纵向横过来,进行统筹) 分解文档,集成平台,可维护性要求。 软件设计必须有自说明特性。不能对文档产生依赖性。软件代码中合适的地方,需要对文档进行恰如其分说明。原则是,每段代码,每处需要理解的地方,如果和总体架构相关,就要有说明。 软件领域需要简化。需要还原软件本来的面目。EDA有泛滥的趋势,软件的各个方面都需要简化。软件形态、需求分析、文档说明、开发工具等。 需求分析过分强调适应生命周期的变化和没有需求分析是一样的。不切实际的面向未来的需求架构的直接结果是软件的复杂和错误百出。 软件只有一个,而观察的视角很多。要采用最适合的观察视角,让软件一目了然。 软件的生成过程和观察过程是两个不同的观念。生成过程又可以区分为:研究过程和工程过程。研究过程可以通过结果,研究报告反映;工程过程则必须采用过程刻画。 软件规范使用的语言一定要有普遍语义,但描述本身具有特殊性;不能强求它的全球唯一。一定要雄视全体,才能选择正确的立足点,这就要求对目前的软件技术有一个了解;要考虑纳入新的发展,那么规范应该分层,把一般的和具体易变的成分分开;要有具体的指导意义,越具体指导意义越大,但通用性则越小。 所谓架构,可能是十分具体应用的代表;不同类别的应用必然有不同的架构。软件架构本身是“应用架构”。因此,不能规范具体的架构。到是可以做:应用架构规范的规范。 逻辑架构的特殊性。可以判断,任何一款实用的软件采取的软件逻辑抽象都是别样的,特例的逻辑。否则,软件不可能那么轻快实用。软件逻辑,鬼魅也。而需求分析,必须是现实实用的,而不是同构/仿真的-这似乎是反对象分析的。因为这里强调的是和软件的交互界面,这个界面远远没有反映现实世界的结构。须知,软件强调的是数据处理,是输入输出。否则,就不能达到最简化。 可能现实世界的结构映射,最适合的方式是数据库 - 采用纯数据结构进行映射。除此之外,能有更合适的技术吗? 面向对象建模是吗?那么对象又如何与现实世界的对象绑定在一起呢? 这再次表明,在软件技术和需求分析之间有鸿沟。软件技术作为特殊的技术,有它的有限性。也反映了,包含软件应用在内的现实架构已经固定。 如果软件是数据处理,是输入输出,那么软件结构也就可以确定了! 可视化、用户操作界面解开了另外的软件世界,因为可视化可以代表用户更抽象的逻辑。用户希望操作可视对象,象操作现实对象一样。软件从模拟现实对象的过程中继承了其结构。 工业控制也开启了新的软件世界,因为软件要从分离的输入建立“综合感知”,感知到设备状态,然后做出响应。 软件有其固有的物理属性,也就是计算的量。算法领域,无论算法的论证多么曲折,求得的结果,物化为软件,总是“早已熟知”的软件。这一区分,是定义软件规范的基石。 算法构造领域是和软件完全不同的领域,算法不是软件。算法类似数学系统。也一如数学系统那样多样。 软件构造。算法总要转化为软件,这就是软件构造问题。寻址系统,数组。软件把自己的生成作为问题,给算法开辟了新的领域。软件生成,是一个“构造-编译”问题。手工构造,自动编译。语言的发展,是一个软件生成的历史。所谓统一建模,所谓设计模式,其实都是软件生成的问题。 需求分析。需求分析本质上是独立的。所谓OOA,面向对象的建模,把程序构造概念上升到需求分析领域可能是不对的。一个先验的,复杂的难于掌握的限制,只会让人对需求分析望而却步;即使勉强掌握,难求对需求分析的创造性发展。需求分析应该专注于需求分析本身,独立发展,一切为了准确、快捷的分析。 需求分析层次一些,抽象一些,自由一些,这样可以充分表达需求的本质。反而可以促进更级别的程序自动生成。 软件生成的历史。软件生成是为了解决人机沟通,让“计算机语言”更接近普通人的思维逻辑。把这种“级计算机语言”翻译成可以执行的代码,就是软件生成(代码生成)的任务。而软件编制是专业人员的事情,因此语言问题的本质其实不那么重要。须知,经过培训,莫尔司码的电报发报可以比说话的语速还快!因此,计算机语言的前途迷茫;实际上也确实迷茫,历史上语言的层出不穷本身就说明了问题,至今仍然如此。在当今,必须建立这样的观点:语言是因人而异的;面对一个语言的时候,要清醒,首先明确“这是为谁设计的语言”;也就是说,需求分析之前的需求是要明确,让什么人来设计软件,然后为他们选择合适的语言。软件生成除了代码生成,还包括另外一个意思:软件构造。这在前面已经论述过了。只是,这里的软件构造机制已经在语言中奠定了。手工参与的软件构造只是语言给出的构造机制的应用。手工的软件构造就是语言构造机制的复制,产生大量的代码,应付实际问题的量。 立体构造。这里还有一个立体问题,实际问题的构造可能产生立体构造,如同建筑,基本的构件组装出复杂的立体结构。这里是建筑设计师的功劳。可能目前我们在语言层面上混淆不清的关键也在这里,没有区分语言和立体构造的责任。一个趋势是语言本身总是试图包揽建筑师的责任。把立体构造独立出来,带来的问题是:这个构造本身必须能够证明自己是正确的。1)能产生软件2)构造逻辑上正确,确实能解决应用问题。构造本身有一个属性,它有通用性。根本原理是通用的;总体构造本身具有一般性,也就是抽象性、实际问题无关性;局部构件具有通用性。也就是说,这里存在容器和容量的区别,构造是容器,实际问题是装在容器中的量。一个好的容器要能顶住容量的压力;一个好的建筑架构要能满足负载和抗振性要求。而架构本身的承受能力是客观的,只与架构本身有关。这也就是说,架构本身自我构造的,因此也就是科学。可能软件构造本身是澄清问题的工作,明确“容量”的特点,为软件构造的选择提供准确的依据,杀鸡不要用牛刀。实际问题的“容量”很容易测量,因为它反映为应用的规模,流程的流量。(架构是什么?架构是否存在?如果我们所说非虚,那么如何为架构下一个定义-一定是一个由具体业务流量和模式支撑的架构) 软件(算法)的构造。一个是数据的复杂性(内在互相关系),一个是计算方法(步骤和缓冲)。从宏观角度,数据关系是更根本的东西。目前的级语言,变量和流程(顺序、分支-步骤;循环-缓冲和迭代)研究的多,而数据复杂性构造不足。 同构现象。CPU指令集合可以说是硬件直接实现的软件。软件帝国从这里提取软件精神,并升华它。从硬件的角度,从寄存器和指令执行流程,体现出的是变量和迭代(顺序更迭,循环往复)。(迭代流程)基于固定寻址的变量,经过寻址接口,可以处理任意数据,从而把迭代流程变成了一般流程。CPU的基本过程,产生了指令和数据,指令天生具有子程序的基因(一般流程),数据天生具有数据结构(寻址能力)的基因。级的构造一般也是这种结构的类似:设计一套类似CPU的机制,支撑程序和数据;独特的“寻址机制”和“CPU处理能力”是实现构造的核心机制;迭代是所有这种机制的动力学和构造方式。而数据化是“寻址机制”的基础。抽象是数据化的工厂,也因此必须研究抽象技术。 抽象技术。所谓抽象,就是具体化,是范围的界定和比对(两种具体化对象之间的比对)。如果范围界定的完整,那么比对建立的联系就是普遍联系,普遍联系也就是所谓抽象原则。 评价标准。软件架构需要评测。这种评测是“在商言商”似的评测。评测的基础是软件架构的具体化。当掌握了架构的构造方法,每种架构本身也就具体化,是一种具体的架构。一种具体化的架构,就可以识别;可以识别则可以客观评测。可以按照立体架构的“压力”、“流量”等概念进行评测。 需求的把握-需求的变化。我们希望永恒不变的需求,核心需求和需求方式(表现和满足步骤);而事实上需求总在演化。软件必须无条件、最大限度地方便需求的表达和需求的满足。软件可能永远只是皮肤,需求源于现实核心深处,软件是一件衣服。这种观点下,软件是没有中心的一种架构。软件架构和需求之间联系的定量评测。 软件和算法的分开 软件的构造作为软件的通用属性 需求的独立 推论:算法是应用的算法。比如数学公式的计算、图形图象的处理、频谱分析、词法和语法分析。因此算法不是通用的软件算法。也因此软件构造是软件规范的一部分,因为它是通用的软件构造技术。 计算技术和应用之间有明显的区别,是两种不同的成分。软件规范是纯粹的,只关心计算技术。而不关心应用建模。计算方法本身早已经被发现了(也就是怎么自动计算,或者说什么是可计算的),剩下的问题只是应用问题。把应用问题的解决纳入软件计算模式。自动计算技术在汇编指令集合那里得到了说明。所谓软件设计是把这种计算方式发扬广大。 所谓算法,就是明确问题,然后发现用自动计算的方式解决问题。从这个意义上说,软件是应用问题导向的。那么,也就是要以问题为中心谈论软件。不同类型的问题需要的解决方式有独特的强调。这也就反映为所谓不同的软件技术。所以,区分软件计算技术和应用问题的成分,是软件规范需要首先识别的东西。 解决问题。本质上是把问题装到变量里面的过程,是放大CPU寄存器的过程。表示层:(把局面、环境;起点和终点需要定义在一个世界里)装进去,组织起来。计算层(展开层):基于表示,定义问题解决步骤(定义运动和过程)。 需求分析。问题描述采用的方法可能应该和软件算法完全分开。否则不能发现问题描述的创造性方法,不能表达问题本质。阐述问题,写文章我们有某篇布局之法;哲学研究我们有严谨的逻辑方法。需求分析,我们一定可以创造自己的方法。这是什么方法?满足使用要求,满足使用流程。离散/隔离各个需求。事实上,面向外部的分析理解和面向内部的分析理解之间有鸿沟。因为这是两个不同的世界。在两个相差悬殊的世界之间,搭建的构造也必然多种多样,以奇为平常。那么,建立联系的媒介少的可怜。可能问题本身也正在于这种联系的分析和设计。 软件的量,是静态的。强调这部分就忽略了活跃的、奇异的、动态的部分。软件的出现不仅仅是被动地适应显示需求,同时也改变了现实需求本身。这种和现实需求融合在一起形成的状态,正是软件活跃的部分。在以前,仅仅以“应用软件”指称是不够的。(操作系统、编译软件、应用软件) 在范畴上,分为三个层次,或说3个范畴域: 1、 活跃的、黏性的动态层次。应用层。和现实之间的界面,是设备逻辑。需求简化、解决方案的奇异性;应用算法的专业性。这是软件形象最活跃的部分。 这里用的是抽象(业务流程)和具体(设备能力)统一的思维方法,构造逻辑的软件过程同时又是可以用具体进行描述的;动态的、物理的分析手段(物理的量)。 业务流程的设计几乎就是艺术设计。 2、 中间层。程序构造层。语言、编译技术、数据结构、设计方法(过程、数据、对象)等可以形式化的计算机科学的任务。对程序能力进行抽象,设计程序自动化生成的一套系统:语言、计算系统、编译系统。这是在静态和活跃部分之间的层次。这里的观念:设计方法、主程序、程序过程(和应用层的过程不是一一对应的)。 3、 静态层。软件的量,度量层。所有程序构造过程的差别消失了。这是软件的静态观点。 每层都有对软件的自己的理念,概念、过程和模型。两个层的对比,则凸显出不可调和的差别。也是所有关于软件的不成熟的印象、抽象产生的地方。 在应用层,抽象的、逻辑过程强一些。想象的部分占据主要的部分。需要对现实的业务,基于设备的具体能力,进行构造。 3个范畴定义了“软件”和“程序”的分别。第1层和第3层论述的是“软件”,而第2层论述的是“程序”。 软件和程序的研究方法不同。程序研究方法是完备的,而软件不完备。 程序开发应当体现软件特性。1)是逻辑的过程,总体的过程和子过程的观察和校验程序。2)软件的量层次上,软件的规模、运行强度和稳定性指标的自测试程序。 第二阶段 一定要有一个标准。软件如衣服,软件的交付文档应当显示出衣服是如何编织起来的。(相对于需求,软件是衣服,非核心;相对于硬件,软件是衣服,包裹) 要有一个理论说明。 架构也是衣服的一个部件,类似衣服的连接方式,模块集合的重心比对。 衣服是一个没有核心的结构。软件也一样要显示出这个特性。 无论如何,我们需要有观察软件的眼光,无论一套软件依据什么样的理论产生。 什么是软件?描述是软件的存在形式(文本格式)。软件一定是可执行的(这是软件的严肃性,精确、定量)。软件是异化的,一般异化为具体、特例(对抽象力最好的归结方式)(没有完美满足需求的软件,相对于需求,软件只能满足固定的需求,而不能满足需求的变化,即一款软件总是具体的;由一般产生出具体的思考方法,也就是构造的方法;或着是磁力打造,一个好的理论一定对现实素材有吸引力,向磁铁一般;这也是在矛盾中建造现实的方法,只要是具体的就肯定是可以分析出潜在矛盾、不完美的,问题不仅仅是分析、认识现实,还要能够构造现实;不存在完美的现实,只存在完美的理论 科学研究的方法是简化。工程的方法是‘相似’,复制发现事物时的状态,那么事物的表现就会复现。 在具体化这里,软件和硬件工作的方法在结果上实现了一致。只是方向不同,软件是从一般进行到具体;硬件一开始就是从具体出发,层层构造,搭建系统。硬件的设计明显具有以工艺、器件为核心的特征。配合器件的特新,进行外围设计。在硬件领域,是‘具体’为上;在软件领域,是‘具体’为下。) 对具体性的解释:组成所有物资的电子、质子、中子是圆的、相同的,但是这些相同的东西组成的原子则有几百种不同。每次量的规模的添加,都导致特殊性的添加。对于软件来说,也是如此。如下的概念是母庸质疑的,软件如同大山,沟壑鲜明。(这种巨大的特殊性,一定是和巨大的需求特殊性相应的)。 “软件以文本形式存在;软件在执行着;软件以个例的形式存在”,归结为在一起就是“软件是具体的”。 一级别的定义:软件与数据和逻辑相关(数据和逻辑是软件的基本语义)。软件与过程相关(积分(存储,数据的数据化)和步骤(逻辑);过程是步骤的遍历,是数据的消长变化)。 执行的异化。区分独立执行和整体执行的概念。独立执行的代码称为模块,否则只是‘片段’。独立性和数据完整性相关,数据越庞大那么不独立的代码片段越多,模块就越大。模块独立性具有比和整体执行所要求的更大的自由度,也就是说整体只是使用了模块一部分的执行能力。模块独立执行获得的自由度是应该能够度量;模块的执行设计应该为了获取更大的自由度;自由度是模块可执行性质量的评定指标。对于整体执行的设计来说,自由度设计可能是设计过程的主导方法,它和全面、完整的需求理解相关,也和需求变化相关;因此自由度设计也是需求定位的设计。 软件的量,也就是软件的能力。这是理解软件解决问题的方式的基础。比如逻辑能力、计算能力、存储能力、图象能力等。 软件是运行的,软件是自我构造的,软件的全体的各个环节都有自己的量。编译、操作系统、文件管理等各环节都是不同分工的软件实现的。 需要构造在功能层次上的互相配合,解释这种完整性。显然每个部分都具有独立的完整性;完整性和完整性的配合构成一个总体的系统。因此未必要求系统的完整性、长期性、稳定性。反过来,系统满足需求的快速性、快速变化适应性、和现实一起变化、消长的特性、瞬态响应特性可能更接近系统的本质。 这好比太极拳,要在一个完满的氛围里运动。 软件能力是比代码一个级别的抽象。又是构成软件内涵的基础语义。 ‘设备能力’的概念更基础,可以统一所有其它能力;又可以作为以硬件为中心的观念的基础。 能力的获得在于‘二分’。在于互相支撑的界面,支撑在一起的双方互为能力。 1.所谓需求分析,我们总是在创造一套新的方法和语言。而最有效的需求分析是自然语言分析。借助人们心目中的全部理解所用到的描述形式。也就是进入到实际存在的需求中去理解需求,分析需求。 因为领域、术语、行业表述习惯的原因,这个阶段千差万别。 2.其次是电脑的使用方式-电脑技术(外设、通信和电脑本身的硬件形态),尝试去设计合适的使用方式和硬件解决方案。 这里有使用环境、专业技术、成本、时间,以及个人习惯等原因,同样是一个精彩的过程。对领域工作方式的熟悉、外设相关的专业技术背景、折中技术决定了这是一个经验至上的活动。这就是电脑使用方式的确定。 3.进一步,确定使用者角色。使用者和使用地点关联。使用地点也就是前面电脑使用方式的一部分。 这是一个沟通过程,也是对有了电脑辅助参与,相关领域习惯改革的问题。 4.然后,进入二元分析阶段:使用者管角度、客观功能角度,分析功能,并完成二者之间的映射。 这个阶段,功能被量化。职能量化。职能和功能之间会有模糊,有授权的转移。这个阶段就是充分考虑这些问题。 5.然后,进入传统的需求分析阶段。 计算架构和功能描述的规格分析。使用者界面规划(详细、规格级别)。 界面规划、功能、架构三者之间组成互动的具体化过程。 最后会产生系统级别的文档。运行实体、接口;系统运行态、实体接口的输入输出规格。 6.然后,实体级别的程序构造阶段。 算法构造和程序构造。主要是从资源占用的角度确定宏观的算法。在这个阶段,是程序文档化阶段。文档这个属于是这个阶段的工具。 最后会产生严格的程序模块的文档。所有这些文档组合起来,可以构成运行流程。这些文档化的程序就是逻辑化的程序本身。 7.最后,编码阶段 用一种具体的语言,按照模块文档的接口、资源、算法要求,编制代码。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

文火冰糖的硅基工坊

你的鼓励是我前进的动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值