当前位置：首页 > news >正文

牌具做网站可以吗中文域名查询网站

news 2026/1/1 16:25:02

牌具做网站可以吗,中文域名查询网站,做php网站教程视频,广州软件开发公司排行榜目录软件重用构件技术基于架构的软件设计 ABSD方法与生命周期抽象功能需求用例抽象的质量和业务需求架构选项质量场景约束基于架构的软件开发模型架构需求需求获取标识构件需求评审架构设计架构文档架构复审架构实现架构演化前言…目录软件重用构件技术基于架构的软件设计 ABSD方法与生命周期抽象功能需求用例抽象的质量和业务需求架构选项质量场景约束基于架构的软件开发模型架构需求需求获取标识构件需求评审架构设计架构文档架构复审架构实现架构演化前言软件重用技术是一种重要的软件开发方法虽然至今软件重用技术还不够成熟距离理想中的软件工厂还有一些距离但是现有的一些重用技术例如中间件、应用服务器等已经改变了开发过程。软件重用软件产品与其他的产品不同是抽象的一旦产生就可以不限制地复制因此重复利用软件产品的意义重大可以节约大量的人力物力。软件重用指的是利用已经存在的软件元素建立新的软件系统这其中的软件元素既可以是软件产品、源代码、也可以是文档、设计思想甚至是领域知识。软件重用可以直接提高软件的开发效率、降低软件的开发成本、缩短软件的开发周期、提高软件质量。常见的软件重用形式包括源代码复用。这是最简单的也是最常见的重用形式但由于软件系统的复杂性很难大规模地重用已有源代码。架构重用。架构重用也很常见随着软件架构风格和设计模式的推广和应用架构重用已经对软件开发产生了重大的影响。应用框架的重用。随着软件技术的发展应用框架的重用变得越来越普遍很多成熟的软件公司都建立了自己的开发框架。在开源社区中世界各地的技术爱好者也在不断地推出应用了各种新技术的开发框架例如应用AOP技术的Spring等业务建模的重用。虽然不同的软件的业务领域各自不同但人们还是总结出了一些常见领域的建模方法重用这些领域模型可以降低因领域知识不足而造成的需求风险。文档以及过程重用。软件文档和软件过程也是软件开发中不可缺少的元素有效地重用这些文档和过程也有助于提高开发效率和软件质量、降低开发成本。软件构件的重用。软件服务的重用。随着Web服务的提出人们越来越关注服务的重用。SOA面向服务框架提出了面向服务的软件架构并且定义了相应的标准。但是SOA还不够成熟相信这一领域在未来的几年中还将取得更大的进展。构件技术构件又称为组件是一个包容、可复用的程序集。首先构件是一个程序集或者说是一组程序的集合。这个集合可能会以各种方式体现出来如源程序或二进制的代码。这个集合整体向外提供统一的访问接口构件外部只能通过接口来访问构件而不能直接操作构件的内部。构件的两个最重要的特征是自包容与可重用。自包容指的是构件的本身是一个功能完整的独立体构件内部与外部的功能界限清晰明确可以独立配置与使用。而可重用既是构件的特点也是构件出现的目的。使用构件技术实现软件复用采用搭积木的方式生产软件就成为软件人员的梦想。构件的开发者和使用者往往不是相同的人或组织所以必须定义构件的标准才能够消除其中的障碍。随着构件技术的发展目前应用比较广泛的构件标准有Java Bean。基于架构的软件设计基于架构的软件设计是一种架构驱动方法。功能的分解。在功能分解中ABSD方法使用已有的基于模块的内聚和耦合技术。通过选择架构风格来实现质量和业务需求。软件模板的使用。软件模板利用了一些软件系统的结构。软件模板是一个特殊类型的软件元素包括描述所有这种类型的元素在共享服务和底层构造的基础上如何进行交互。软件模板还包括属于这种类型的所有元素的功能这些功能的例子有每个元素必须记录某些重大事件每个元素必须为运行期间的外部诊断提供测试点等。在软件产品线系统中软件模板显得格外重要因为新元素的引入是一个通用的技术。这个技术用来使产品线架构适应一个特定的产品。 ABSD方式是递归的且迭代的每一个步骤都是清晰定义的。因此不管设计是否完成架构总是清晰的这有助于降低架构设计的随意性。 ABSD方法与生命周期 ABSD方法在生命周期中的位置。尽管我们没有描述一个需求获取、组织或跟踪的特定方法但还是假设一个需求阶段至少部分完成从需求获取包括功能需求、质量和业务需求、约束。ABSD方法的输出是三个视图的概念构件的集合包括能够产生每个概念构件的假设、软件模板的集合和那些已经做出具体实现的决策我们把具体实现决策当作附加约束来维护。在ABSD方法中必须记录所有做出的决策及这些决策的原理这有利于决策的可跟踪性和决策评审。 ABSD方法的输入由下列部分组成抽象功能需求包括变化的需求和通用的需求用例实际功能需求抽象的质量和业务需求质量因素实际质量和业务需求架构选项约束抽象功能需求 ABSD方法假定需求阶段的输出之一是功能需求的抽象描述包括这些需求的粗略变化描述。当获取需求时考虑所有最终用户是重要的。对一个特定系统来说通常有不同类型的最终用户。不同的系统管理员数据库管理员、系统管理员、网络管理员等都是可以是最终用户。维护工程师也可以是系统的最终用户。总之一个最终用户就是当系统运行时使用系统的任何人员。与抽象功能需求相联系的是对公共需求和与这些需求相关的粗略变化的描述在设计阶段理解这些需求之间的依赖关系是至关重要的。我们必须在某些抽象级别上获取功能需求产品的详细需求往往要等具体产品开发完成后才能知道。当详细需求明确时抽象功能的获取为详细需求提供了分类。用例用例是一个或多个最终用户系统之间的交互的具体表述在这里最终用户既可以是操作人员也可以是与系统进行交互操作的其他软件系统。虽然用例很容易找到和创新甚至可能有成百上千个但是因为我们需求分析用例所以必须限制用例的数量。在架构设计阶段只有重要的用例才有用。我们必须对所创建的用例进行分组设置优先级以便筛选出最重要的用例剩下的用例可以在设计阶段的任何时候创建。抽象的质量和业务需求必须对待构建系统的质量和业务需求进行编号每个质量属性都包含一个特定的行为以及希望得到的结果质量需求要尽量具体化。架构选项对每个质量和业务需求我们都要列举能够满足该需求的所有可能的架构。例如如果需求是支持一系列不同的用户界面则可能的架构选择就是把不同的用户界面分解成不同的构件。如果需求是保持操作系统的独立性则可能的架构选择就是构建虚拟的操作系统层接受所有的操作系统调用并解释之为当前操作系统所能的支持。只需要列举所有可能的选项而不需要对这些架构选项进行决策这种列举取决于设计师的经验即可来自某些书籍介绍也可直接来自设计师本身的实践。质量场景用例功能需求具体化一样质量场景使质量需求具体化。质量场景使质量需求的特定扩充。和用例一样质量场景也很容易找到和创建可以创建很多个。我们必须对质量场景进行分组设置优先级只需要验证最重要的质量场景。约束约束是一个前置的设计决策设计过程本身包含决策。某些决策可以直接由业务目标导出而无须考虑对设计的影响。例如如果一个公司在某个中间件产品上投入大量资金那么在产品的选择上就可以不必考虑其他决策。在需求获取阶段约束主要来自系统的业务目标。在某些特殊情况下约束由遗留系统决定。今天几乎没有软件系统不参考已有系统的常见的情况下新老系统同时并存或者新系统替代老系统但是必须尽可能重用老系统的功能。在设计阶段虽然这些遗留系统处于被设计系统的外部但是设计师必须考虑遗留系统的特征。也就是说在某种程度上遗留系统影响着当前的设计因此理解遗留系统的结构和解决问题的技术都很重要。出于商业的目的可能要求重用遗留系统的构件这种需求就变成了约束。基于架构的软件开发模型基于架构的软件开发模型ABSDM把整个基于架构的软件过程划分为架构需求、设计、文档化、复审、实现、演化等6个子过程。架构需求需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。架构需求受技术环境和架构设计师的经验影响。需求过程主要是获取用户需求标识系统种所要用到的构件。如果以前有类似的系统架构的需求我们可以从需求库中取出加以利用和修改以节省需求获取的时间减少重复劳动提高开发效率。需求获取架构需求一般来自三个方面分别是系统的质量目标系统的业务目标和系统开发人员的业务目标。软件架构需求获取过程主要是定义开发人员必须实现的软件功能使得用户能完成他们的任务从而满足业务上的功能需求。与此同时还要获得软件质量属性满足一些非功能需求。标识构件上图所示虚框部分属于标识构件过程该过程为系统生产初始逻辑结构包含大致的构件。这一过程又可以分为三步来实现。第一步生产类图。生产类图的CASE工具有很多例如Rational Rose就能生成类图。第二步对类进行分组。在生成的类图基础上使用一些标准对类进行分组可以大大简化类图结构使之更清晰。一般地与其他类隔离的类形成一个组由泛化关联的类组成一个附加组由聚合或组合关联的类也形成一个附件组。第三步把类打包成构件。把在第二步得到的类打包成构件这些构件可以分组合并成更大的构件。需求评审组织一个由不同代表如分析人员、客户、设计人员、测试人员组成的小组对架构需求及相关构件进行仔细的审查。审查的主要内容包括所获取的需求是否真实反映了用户的需求类的分组是否合理构件合并是否合理等。必要时可以在“需求-标识构件-需求评审”之间进行迭代。架构设计架构需求用来激发和调整设计决策不同的视图被用来表达与质量目标有关的信息。架构设计是一个迭代的过程如果要开发的系统能够从已拥有的系统中导出大部分则可以使用已有系统的设计过程。软件架构设计过程如图提出软件架构模型在建立架构的初期选择一个合适的架构风格是首要的。在这个风格基础上开发人员通过架构模型可以获得关于架构属性的理解。此时虽然这个模型是理想化的其中的某些部分可能错误地表示了应用的特征但是该模型为将来的实现和演化过程建立了目标。把已标识的构件映射到软件架构中把在架构需求阶段已标识的构件映射到架构中将产生一个中间结构这个中间结构只包含哪些能明确适合架构模型的构件。分析构件之间的相互作用为了把所有已标识的构件集成到架构中必须认真分析这些构件的相互作用和关系。产生软件架构一旦决定了关键构件之间的关系和相互作用就可以在第二阶段得到的中间架构的基础上进行细化。设计评审一旦设计了软件架构我们必须邀请独立于系统开发的外部人员对架构进行评审。架构文档绝大多数的架构都是抽象的由一些概念上的构件组成。例如层的概念在任何程序设计语言中都不存在。因此要让系统分析师和程序员去实现架构还必须把架构进行文档化。文档是在系统演化的每一个阶段系统设计与开发人员的通信媒介是为验证架构设计和提炼或修改这些设计所执行预先分析的基础。架构文档化过程的主要输出结果是架构需求规格说明和测试架构需求的质量设计说明书这两个文档。生成需求模型构件的精确的形式化的描述作为用户和开发者之间的一个约定。软件架构的文档要求与软件开发项目中的其他文档是类似的。文档的完整性和质量是软件架构成功的关键因素。文档要从使用者的角度进行编写必须分发给所有与系统有关的开发人员并且保证开发者手上的文档是最新的。架构复审上图中可以看出架构设计、文档化和复审是一个迭代的过程。从这方面来说在一个主版本的软件架构分析之后要安排一次由外部人员用户代表和领域专家参加的复审。复审的目的是标识潜在的风险以及早发现架构设计中的缺陷和错误包括架构能否满足需求、质量需求是否在设计中得到体现、层次是否清晰、构件的划分是否合理、文档表达是否明确、构件的设计是否满足功能与性能的要求等等由外部人员进行复审的目的是保证架构的设计能够公正的进行检验使组织的管理者能够决定正式实现架构。架构实现所谓的实现就是用实体来显示出一个软件架构即要符合架构所描述的架构性设计决策分割成规定的构件按规定方式互相交互。架构的实现过程如图上图中的虚框部分是架构实现过程。整个实现过程是以复审后的文档化的架构说明书为基础的每个构件必须满足软件架构中说明的对其他构件的责任。这些决定即实现的约束是在系统级或项目范围内做出的每个构件上工作的实现者是看不见的。在架构说明书中已经定义了系统中的构件与构件之间的关系。因为在架构层次上构件接口约束对外唯一地代表了构件所以可以从构件库中查找符合接口约束的构件必要时开发新的满足要求的构件。然后按照设计提供的结构通过组装支持工具把这些构件的实现体组装起来完成整个软件系统的连接与合成。最后一步是测试包括单个构件的功能性测试和被组装应用的整个功能和性能测试。架构演化在构件开发过程中最终用户的需求可能还有变动。在软件开发完毕正常运行后由一个单位移植到另一个单位需求也会发生变化。在这种情况下就必须相应地修改软件架构以适应新的软件需求。架构演化过程如下图所示。脚骨演化是使用系统演化步骤去修改应用以满足新的需求。主要包括以下七个步骤。需求变动归类首先必须对用户需求的变化进行分类使变化的需求与已有构件对应。对找不到对应构件的变动也要做好标记在后续的工作中将创建新的构件以对应这部分变化的需求。制定架构演化计划在改变原有结构之前开发组织必须制定一个周密的架构演化计划作为后续演化开发工作的指南。修改、增加或删除构件在演化计划的基础上开发人员可根据在第一步得到的需求变动的归类情况决定是否修改或删除存在的构件、增加新的构件。最后对修改和增加的构件进行功能性测试。更新构件的相互作用随着构件的增加、删除和修改构件之间的控制流必须得到更新。构件组装与测试通过组装支持工具把这些构件的实现组装起来完成整个软件系统的连接与合成形成新的架构。然后对组装后的系统的整体功能和性能进行测试。技术评审对以上步骤进行确认进行技术评审。评审组装后的架构是否反映需求变动符合用户需求。如果不符合则需要进行2到6步之间进行迭代。产生演化后的架构在原来的系统上所作修改必须集成到原来的架构中完成一次演化过程。

查看全文

http://www.w-s-a.com/news/432860/