精华内容
下载资源
问答
  • 案例分析必考题型
  • 【解答】 【问题1】 效用树质量属性包括:性能、可用性、可靠性、健壮性、安全性、可修改性、可变性、易用性、可测试性、功能性和互操作性等。 性能质量,(c)为响应时间,(k)为吞度量,所以(3)填(k) 因为...

    【说明】

            某单位为了建设健全的公路桥梁养护管理档案,拟开发一套公路桥梁在线管理系统。在系统的需求分析与架构设计阶段,用户提出的需求、质量属性描述和架构特性如下:

    1.  (a) 系统用户分为高级管理员、数据管理员和数据维护员等三类;
    2.  (b) 系统应该具备完善的安全防护措施,能够对黑客的攻击行为进行检测与防御;
    3.  (c) 正常负载情况下,系统必须在 0.5 秒内对用户的查询请求进行响应;
    4.  (d) 对查询请求处理时间的要求将影响系统的数据传输协议和处理过程的设计;
    5.  (e) 系统的用户名不能为中文,要求必须以字母开头,长度不少于 5 个字符; 
    6.  (f) 更改系统加密的级别将对安全性和性能产生影响;
    7.  (g) 网络失效后,系统需要在 10 秒内发现错误并启用备用系统;
    8.  (h) 查询过程中涉及到的桥梁与公路的实时状态视频传输必须保证画面具有 1024*768 的分 辨率, 40 帧 /秒的速率;
    9.  (i) 在系统升级时,必须保证在 10 人月内可添加一个新的消息处理中间件;
    10.  (j) 系统主站点断电后,必须在 3 秒内将请求重定向到备用站点;
    11.  (k) 如果每秒钟用户查询请求的数量是 10 个,处理单个请求的时间为 30 毫秒,则系统应保证在 1 秒内完成用户的查询请求;
    12.  (l) 对桥梁信息数据库的所有操作都必须进行完整记录;
    13.  (m) 更改系统的 Web 界面接口必须在 4 人周内完成;
    14.  (n) 如果"养护报告生成"业务逻辑的描述尚未达成共识,可能导致部分业务功能 模块规则的 矛盾,影响系统的可修改性 ;
    15.  (o) 系统必须提供远程调试接口,并支持系统的远程调试。 

    在对系统需求,质量属性描述和架构特性进行分析的基础上,系统的架构师给出了三个候选的架构设计方案,公司目前正在组织系统开发的相关人员对系统架构进行评估。

    【问题1】

            在架构评估过程中,质量属性效用树是对系统质量属性进行识别和优先级排序的重要工具。请给出合适的质量属性填入图中 (1)、(2) 空白处;并选择题干描述的 (a)~(o) ,填入(3)~(6) 空白处,完成该系统的效用树。


     【问题2】

            在架构评估过程中,需要正确识别系统的架构风险、敏感点和权衡点,并进行合理的架构决策。请用 300 字以内的文字给出系统架构风险、敏感点和权衡点的定义,并从 题干(a)~(o) 中分别选出1个对系统架构风险、敏感点和权衡点最为恰当的描述。

    【解答】

    【问题1】

    • 效用树质量属性包括:性能、可用性、可靠性、健壮性、安全性、可修改性、可变性、易用性、可测试性、功能性和互操作性等。
    • 性能质量,(c)为响应时间,(k)为吞度量,所以(3)填(k)
    • 因为(b)为安全性,所以(1)填安全性,(f)也为安全性,所有(4)填(f)。
    • 可用性(g)为网络故障,(j)为硬件故障,所以(5)填(j)
    • (i)为可修改性,所以(2)填可修改性,(m)也为可修改性,所以(6)填(m)

    【问题2】

    • 风险点:架构都有与之相关的风险,无论是涉及可用性、可扩展性还是数据完整性的风险,即可能引起风险的因素,可称为风险点。架构风险分析是架构的关键活动之一。通过不断分析风险,架构师可以解决架构中的缺陷,并采取纠正措施来降低风险。
    • (n)为风险点
    • 敏感点:敏感点是一个或多个构件的特性。研究敏感点可使设计人员或分析员明确在搞清楚如何实现质量目标时应注意什么。
    • (c)为敏感点,因为改变加密级别回对性能产生非常重要的影响。
    • 权衡点:是影响多个质量属性的特性,是多个质量属性的敏感点。
    • (f)为权衡点,改变加密级别可能会对安全性和性能产生非常重要的影响。提高加密级别可以提高安全性,但可能要耗费更多的处理时间,影响系统性能。如果某个机密消息的处理有严格的时间延迟要求,则加密级别可能就会成为一个权衡点。

    【参考】

    软件质量属性

    • 性能(Performance)是指系统的响应能力,即要经过多长时间才能对某个事件做出响应,或者在某段时间内系统所能处理事件的个数。
    • 可用性(Availability)是系统能够正常运行的时间比例。
    • 可靠性(Reliability)是指软件系统在应用或错误面前,在意外或错误使用的情况下维持软件系统功能特性的基本能力。
    • 健壮性(Robustness)是指在处理或环境中,系统能够承受压力或变更的能力。
    • 安全性(Security)是指系统向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。
    • 可修改性(Modification)是指能够快速地以较高的性能价格比对系统进行变更的能力。
    • 可变性(Changeability)是指体系结构经扩充或变更成为新体系结构的能力。
    • 易用性(Usability)是衡量用户使用一个软件产品完成指定任务的难易程度。
    • 可测试性(Testability)是指软件发现故障并隔离、定位其故障的能力特性,以及在一定的时间和成本前提下,进行测试设计、测试执行的能力。
    • 功能性(Functionality)是系统所能完成所期望工作的能力。
    • 互操作性(Inter-operation)是指系统与外界或系统与系统之间的相互作用能力。

     

    展开全文
  • 案例分析必考题型
  • 欢迎大家关注公众号「JAVA前线」查看更多精彩分享文章,主要包括源码分析、实际应用、架构思维、职场分享、产品思考等等,同时欢迎大家加我个人微信「java_front」一起交流学习 1 质量属性 在系统设计和开发过程中...

    欢迎大家关注公众号「JAVA前线」查看更多精彩分享文章,主要包括源码分析、实际应用、架构思维、职场分享、产品思考等等,同时欢迎大家加我个人微信「java_front」一起交流学习


    1 质量属性

    在系统设计和开发过程中,我们比较容易关注系统的功能维度,例如有没有实现预期功能,输入参数和输出参数是否匹配等等,这是比较容易衡量的。

    但是我们不能就此止步,因为满足功能是系统的基本要求,还需要关注系统的非功能维度,例如系统性能是否优秀,代码可扩展性如何,出现异常是否可以自动降级等等,这些指标决定了系统能否提供高质量的服务。

    我之前在文章《结构化思维如何指导技术系统优化》提到了三个质量属性:高性能、高可用、高扩展。本文我们可以充实为六个质量属性:性能、可用性、可修改性、可靠性、安全性、易用性。


    01 质量属性.jpg


    1.1 性能

    1.1.1 如何定义

    性能有两个定义维度:第一个维度是单位时间内可以做多少事情,第二个维度是做完单位数量的事情需要多少时间,常用以下参数进行量化:

    QPS:每秒处理请求数

    TPS:每秒处理事务数

    并发数:同一时刻处理请求数/事务数

    响应时间:系统对请求做出响应的时间

    并发数 = QPS x RT


    1.1.2 如何提升

    提升性能可以从两个维度思考,第一个维度是时间维度,从事前、事中、事后三个时间节点进行优化。事前是指在访问最开始就拒绝无效流量。事中可以使用提高并发度(并发编程),增加资源(服务器、分布式缓存、读写分离,分库分表),减少交互(批量请求)等方案。事后是指数据分析需求可以放到离线数据中心进行,不要放在主应用和主数据库进行。

    第二个维度是层次维度,每一层都可以进行优化。系统架构一般分为数据层、缓存层、服务层、网关层、客户端、代理层,每一层都可以进行优化,每一层都可以按照事前、事中、事后进行优化,而不是一提到优化就是加缓存,应该更加全面地思考。


    10 总体分层.jpg


    1.2 可用性

    1.2.1 如何定义

    可用性是指系统正常运行时间占总运行时间比例,业界常用X个9指标进行量化,例如可用性达到5个9,那么全年系统不可用时间只有5分钟:


    02 可用性.jpg


    1.2.2 如何提升

    (1) 非线性

    我们从另一个概念理解可用性:非线性,这个概念在生活中无处不在。

    假设要赶早上8点钟的火车,如果6:30出发可以在7:00到达车站,所以得到一个结论:只要30分钟就可以到达车站。

    如果早上睡晚一点7:15出发,那么按照预期7:45可以到达车站。但是最可能的结果是错过这趟火车。因为正好遇上早高峰导致至少需要1个小时才能到达车站。

    我们再分析一个互联网秒杀场景。假设秒杀系统当每秒30个请求时,响应时间是10毫秒。如果按照线性思维可以做出如下设计:

    每秒30个访问量响应时间10毫秒

    每秒300个访问量响应时间100毫秒

    每秒3000个访问量响应时间1000毫秒

    如果按照这个思路做系统设计将会发生重大错误。因为当每秒3000个访问量发生时,响应时间可能不是1000毫秒,而是可能直接导致系统崩溃。

    这就是非线性,事物不是简单线性叠加关系,当达到某个临界值时会造成一种截然不同的结果。


    (2) 提升策略

    冗余 + 自动故障转移

    最基本的冗余策略就是主从模式。原理是准备两台机器,部署了同一份代码,在功能层面是相同的,都可以对外提供相同的服务。

    一台机器启动提供服务,这就是主服务器。另一台机器启动在一旁待命,不提供服务,随时监听主服务器的状态,这就是从服务器。当发现主服务器出现故障时,从服务器立刻替换主服务器,继续为用户提供服务。

    自动故障转移策略是指当主系统发生异常时,应该可以自动探测到异常,并自动切换为备用系统。不应该只依靠人工去切换成,否则故障处理时间会显著增加。

    降级策略

    当系统遇到无法承受的压力时,选择暂时关闭一些非关键的功能,或者延时提供一些功能,把此刻所有的资源都提供给现在最关键的服务。

    在秒杀场景中下订单就是最核心最关键的功能。当系统压力将要到达临界值时,可以暂时先关闭一些非核心功能如查询功能。

    还有一种降级策略,当系统依赖的下游服务出现错误,甚至已经完全不可用了,那么此时就不能再调用这个下游服务了,否则可能导致雪崩。所以直接返回兜底方案,把下游服务直接降级。

    延时策略

    用户下订单成功后就需要进行支付。假设秒杀系统下订单每秒访问量是3000,有没有必要将每秒3000次访问量压力传递给支付服务器?

    答案是没有必要。因为用户秒杀成功后可以稍晚付款,例如可以跳转到一个支付页面,提示用户只要在10分钟内支付完成即可。

    这样流量就被分摊至几分钟,有效保护了系统。技术架构还可以使用消息队列做缓冲,让下游系统根据处理能力拉取消息。

    隔离策略

    物理隔离:应用分别部署在不同物理机、不同机房,资源之间不会互相影响。

    线程隔离:不同类型的请求进行分类,交给不同的线程池处理,当一类请求出现高耗时和异常,不影响另一类请求访问。


    1.3 可修改性

    1.3.1 如何定义

    可修改性是指是否能够以较高的性价比对系统进行变更的能力,可以分为以下四种类型:

    可扩展性:系统扩展新构件时对其它构件的影响程度

    可维护性:系统修改旧构件时对其它构件的影响程度

    结构重组:重新组织构件关系的难易程度

    可移植性:在不同硬件平台、编程语言、操作系统间移植的难易程度


    1.3.2 如何提升

    可修改性最终还是在解决牵一发而动全身的复杂性问题,复杂业务之所以复杂,一个重要原因是涉及角色或者类型较多,如果平铺直叙地进行设计会出现if-else代码块,可读性和可修改性都很低。

    我们分析一个下单场景。当前有ABC三种订单类型:A订单价格9折,物流最大重量不能超过9公斤,不支持退款。B订单价格8折,物流最大重量不能超过8公斤,支持退款。C订单价格7折,物流最大重量不能超过7公斤,支持退款。按照需求字面含义平铺直叙地写代码也并不难:

    public class OrderServiceImpl implements OrderService {
    
        @Resource
        private OrderMapper orderMapper;
    
        @Override
        public void createOrder(OrderBO orderBO) {
            if (null == orderBO) {
                throw new RuntimeException("参数异常");
            }
            if (OrderTypeEnum.isNotValid(orderBO.getType())) {
                throw new RuntimeException("参数异常");
            }
            // A类型订单
            if (OrderTypeEnum.A_TYPE.getCode().equals(orderBO.getType())) {
                orderBO.setPrice(orderBO.getPrice() * 0.9);
                if (orderBO.getWeight() > 9) {
                    throw new RuntimeException("超过物流最大重量");
                }
                orderBO.setRefundSupport(Boolean.FALSE);
            }
            // B类型订单
            else if (OrderTypeEnum.B_TYPE.getCode().equals(orderBO.getType())) {
                orderBO.setPrice(orderBO.getPrice() * 0.8);
                if (orderBO.getWeight() > 8) {
                    throw new RuntimeException("超过物流最大重量");
                }
                orderBO.setRefundSupport(Boolean.TRUE);
            }
            // C类型订单
            else if (OrderTypeEnum.C_TYPE.getCode().equals(orderBO.getType())) {
                orderBO.setPrice(orderBO.getPrice() * 0.7);
                if (orderBO.getWeight() > 7) {
                    throw new RuntimeException("超过物流最大重量");
                }
                orderBO.setRefundSupport(Boolean.TRUE);
            }
            // 保存数据
            OrderDO orderDO = new OrderDO();
            BeanUtils.copyProperties(orderBO, orderDO);
            orderMapper.insert(orderDO);
        }
    }
    

    上述代码从功能上完全可以实现业务需求,但是程序员不仅要满足功能,还需要思考代码的可维护性。如果新增一种订单类型,或者新增一个订单属性处理逻辑,那么我们就要在上述逻辑中新增代码,如果处理不慎就会影响原有逻辑。

    为了避免牵一发而动全身这种情况,设计模式中的开闭原则要求我们面向新增开放,面向修改关闭,我认为这是设计模式中最重要的一条原则。

    需求变化通过扩展,而不是通过修改已有代码实现,这样就保证代码稳定性。扩展也不是随意扩展,因为事先定义了算法,扩展也是根据算法扩展,用抽象构建框架,用实现扩展细节。标准意义的二十三种设计模式说到底最终都是在遵循开闭原则。

    如何改变平铺直叙的思考方式?这就要为问题分析加上纵向和横向两个维度,我选择使用分析矩阵方法,其中纵向表示策略,横向表示场景:


    05 订单_分析矩阵.jpg


    (1) 纵向做隔离

    纵向维度表示策略,不同策略在逻辑上和业务上应该是隔离的,本实例包括优惠策略、物流策略和退款策略,策略作为抽象,不同订单类型去扩展这个抽象,策略模式非常适合这种场景。本文详细分析优惠策略,物流策略和退款策略同理。

    // 优惠策略
    public interface DiscountStrategy {
        public void discount(OrderBO orderBO);
    }
    
    // A类型优惠策略
    @Component
    public class TypeADiscountStrategy implements DiscountStrategy {
    
        @Override
        public void discount(OrderBO orderBO) {
            orderBO.setPrice(orderBO.getPrice() * 0.9);
        }
    }
    
    // B类型优惠策略
    @Component
    public class TypeBDiscountStrategy implements DiscountStrategy {
    
        @Override
        public void discount(OrderBO orderBO) {
            orderBO.setPrice(orderBO.getPrice() * 0.8);
        }
    }
    
    // C类型优惠策略
    @Component
    public class TypeCDiscountStrategy implements DiscountStrategy {
    
        @Override
        public void discount(OrderBO orderBO) {
            orderBO.setPrice(orderBO.getPrice() * 0.7);
        }
    }
    
    // 优惠策略工厂
    @Component
    public class DiscountStrategyFactory implements InitializingBean {
        private Map<String, DiscountStrategy> strategyMap = new HashMap<>();
    
        @Resource
        private TypeADiscountStrategy typeADiscountStrategy;
        @Resource
        private TypeBDiscountStrategy typeBDiscountStrategy;
        @Resource
        private TypeCDiscountStrategy typeCDiscountStrategy;
    
        public DiscountStrategy getStrategy(String type) {
            return strategyMap.get(type);
        }
    
        @Override
        public void afterPropertiesSet() throws Exception {
            strategyMap.put(OrderTypeEnum.A_TYPE.getCode(), typeADiscountStrategy);
            strategyMap.put(OrderTypeEnum.B_TYPE.getCode(), typeBDiscountStrategy);
            strategyMap.put(OrderTypeEnum.C_TYPE.getCode(), typeCDiscountStrategy);
        }
    }
    
    // 优惠策略执行
    @Component
    public class DiscountStrategyExecutor {
        private DiscountStrategyFactory discountStrategyFactory;
    
        public void discount(OrderBO orderBO) {
            DiscountStrategy discountStrategy = discountStrategyFactory.getStrategy(orderBO.getType());
            if (null == discountStrategy) {
                throw new RuntimeException("无优惠策略");
            }
            discountStrategy.discount(orderBO);
        }
    }
    

    (2) 横向做编排

    横向维度表示场景,一种订单类型在广义上可以认为是一种业务场景,在场景中将独立的策略进行串联,模板方法设计模式适用于这种场景。

    模板方法模式一般使用抽象类定义算法骨架,同时定义一些抽象方法,这些抽象方法延迟到子类实现,这样子类不仅遵守了算法骨架约定,也实现了自己的算法。既保证了规约也兼顾灵活性,这就是用抽象构建框架,用实现扩展细节。

    // 创建订单服务
    public interface CreateOrderService {
        public void createOrder(OrderBO orderBO);
    }
    
    // 抽象创建订单流程
    public abstract class AbstractCreateOrderFlow {
    
        @Resource
        private OrderMapper orderMapper;
    
        public void createOrder(OrderBO orderBO) {
            // 参数校验
            if (null == orderBO) {
                throw new RuntimeException("参数异常");
            }
            if (OrderTypeEnum.isNotValid(orderBO.getType())) {
                throw new RuntimeException("参数异常");
            }
            // 计算优惠
            discount(orderBO);
            // 计算重量
            weighing(orderBO);
            // 退款支持
            supportRefund(orderBO);
            // 保存数据
            OrderDO orderDO = new OrderDO();
            BeanUtils.copyProperties(orderBO, orderDO);
            orderMapper.insert(orderDO);
        }
    
        public abstract void discount(OrderBO orderBO);
    
        public abstract void weighing(OrderBO orderBO);
    
        public abstract void supportRefund(OrderBO orderBO);
    }
    
    // 实现创建订单流程
    @Service
    public class CreateOrderFlow extends AbstractCreateOrderFlow {
    
        @Resource
        private DiscountStrategyExecutor discountStrategyExecutor;
        @Resource
        private ExpressStrategyExecutor expressStrategyExecutor;
        @Resource
        private RefundStrategyExecutor refundStrategyExecutor;
    
        @Override
        public void discount(OrderBO orderBO) {
            discountStrategyExecutor.discount(orderBO);
        }
    
        @Override
        public void weighing(OrderBO orderBO) {
            expressStrategyExecutor.weighing(orderBO);
        }
    
        @Override
        public void supportRefund(OrderBO orderBO) {
            refundStrategyExecutor.supportRefund(orderBO);
        }
    }
    

    1.4 可靠性

    1.4.1 如何定义

    可靠性包括容错性和健壮性,系统面对错误输入仍能保证正确输出的能力,可以分为两种类型:系统可靠性和业务可靠性。

    系统可靠性是指面对出现基本错误的输入,系统能够识别和拦截,而不是任由其在构件中传递,造成错误数据或者引发系统异常。例如空值引发的空指针异常,不应该出现在系统中。

    业务可靠性是指输入参数在基本校验通过的情况下,系统能够进行业务校验,不会引发超出业务预期的输出结果。例如电商系统中的超卖现象,重复创建订单现象都是业务可靠性较低的表现。


    1.4.2 如何提升

    (1) 拦截

    提升可靠性的关键是应该尽早在上层识别并拦截异常数据,阻止其在构件中流动,避免产生系统异常和错误数据,尤其当产生错误数据后,数据修复难度大。

    提升系统可靠性可以在服务入口增加判空校验、参数类型校验、范围校验、合法枚举值校验等基本校验,一旦发现异常直接拒绝。

    提升业务可靠性可以增强业务校验,例如库存预扣减,活动有效期校验,参与活动次数校验,扣减库存校验,分布式锁控制并发等方案,如果校验规则复杂可以引入规则引擎进行条件组合,不满足业务条件直接拒绝请求。


    (2) 告警

    如果第一阶段没有将异常输入拦截成功,那么就要在发生异常时及时感知,异常分为系统异常和业务异常。

    系统异常是不允许出现的异常,例如空指针,操作数据库失败等异常,一旦出现就要立即告警。

    业务异常可以分为以下类型:

    业务异常:单位时间出现X次需要告警

    延时监控:某指标单位时间内是否变化

    数据监控:单位时间数据指标是否正常


    1.5 安全性与易用性

    安全性是指系统防止非法用户访问的能力,易用性是指系统使用的难易程度,本文不展开论述,下一个章节会再提到。


    2 架构评估方法

    2.1 三种评估方法

    因为涉及到众多变量和场景,所以评估一个复杂技术系统的质量并不是一件容易的事情。业界有以下三种评估方法:

    第一是基于问卷的方式,通过问卷调查对系统比较熟悉的相关人员得到结论,这种方式主观性很强。

    第二是基于度量的方式,对系统指标完全量化,基于量化指标评价系统,这种方式需要评估者对系统非常熟悉。

    第三种是基于场景的方式,筛选出系统的关键场景,根据系统在不同场景中的表现进行评估,这种方式具有一定的主观性,需要评估者对系统较为熟悉,这也是目前较为流行的架构评估方法。

    架构权衡评估方法(ATAM)全称是 Architecture Tradeoff Analysis Method,由卡梅隆大学软件工程协会提出,是一种基于场景的架构评估方法,核心是结合质量属性效用树对系统进行评价,确定风险点、敏感点、权衡点,并对系统架构做出决策和折中。

    ATAM分为以下步骤,其中123为描述和介绍阶段,456为调查和分析阶段,78为测试阶段,9为报告阶段。


    03 ATAM.jpg


    2.2 ATAM实例

    本文以《结合DDD讲清楚编写技术方案的七大维度》足球运动员信息管理系统为例看看ATAM如何实施。

    第一阶段是描述和介绍阶段,首先由架构师向大家介绍什么是ATAM方法,其次由产品经理介绍开发足球运动员信息管理系统商业动机,最后由架构师介绍系统整体架构,例如怎样划分领域,系统分为持久层、缓存层、中间件、业务中台、服务层、网关层、客户端和代理层等等。

    第二阶段是调查和分析阶段,不同需求方均提出了相关需求,所涉及质量场景如下:

    (1) 在100毫秒内响应用户请求

    (2) 主数据库发生故障后,10秒内自动切换至从库

    (3) 主机房发生故障后,5分钟内请求重定向至灾备机房

    (4) 新增球员比赛和训练指标,开发工作在5人日内完成

    (5) 使用包含SSL数字证书的HTTPS访问协议

    (6) 球员信息管理界面要求简单易用

    (7) 出现异常引导用户至错误页面,不能展示异常栈信息

    (8) 对于球员信息配置功能的灵活度尚未达成共识,影响了系统可修改性

    (9) 对于球员比赛实时收集响应时间的要求,影响了系统数据存储设计

    (10) 主教练提出了训练指标新模式,影响了系统性能和可修改性


    根据上述场景生成质量属性效用树,(1)属于性能,(2)(3)属性可用性,(4)属于可修改性,(5)属于安全性,(6)属于易用性,(7)属于可靠性:


    04 质量属性效用树.jpg


    我们再根据这些场景分析系统的风险点、敏感点、权衡点。风险点是指某些操作会给系统带来隐患和风险,(8)属于风险点。敏感点是指为了实现某个特定质量属性,一个或多个系统组件所具有的特性,(9)属于敏感点。权衡点是指某些操作会影响系统的多个质量属性,(10)属于权衡点。

    第三个阶段是测试阶段,根据足球运动员信息管理系统特性,我们首先确定场景优先级,由高到低分别是:性能、可靠性、可修改性、安全性、可用性、易用性。

    架构权衡分析方法所谓权衡在此得到了体现,质量属性每个都很重要,但是根据系统特点需要对质量属性有优先级排序,架构设计时需要所有权衡和折中。

    确定了优先级之后,我们需要具体阐述针对每个质量属性系统采取了哪些方案,例如提升性能使用了缓存,提升可修改性使用了策略模式,提升可靠性使用了统一异常处理框架等等,具体方案可以参考本文第一章节。

    第四个阶段是报告阶段,我们将评估过程和结果都汇总整理成文档,其中包括质量属性效用树、风险点、敏感点、权衡点和每次评估会议纪要,以及最终的架构决策。


    3 文章总结

    第一系统满足功能性需求是最基本的要求,作为架构师不能就此止步,不仅应该关注功能性需求,还应该关注非功能性需求,质量属性就是衡量系统质量的重要指标。

    第二架构评估方法分为基于问卷、基于度量、基于场景的方式,目前业内较为流行的是基于场景的评估方法,ATAM是一种优秀的基于场景评估方法。

    第三ATAM以质量属性效用树为核心,帮助架构师识别项目风险点、敏感点、权衡点,指导架构师做出合理架构决策。


    4 延伸阅读

    《结构化思维如何指导技术系统优化》

    《结合DDD讲清楚编写技术方案的七大维度》

    欢迎大家关注公众号「JAVA前线」查看更多精彩分享文章,主要包括源码分析、实际应用、架构思维、职场分享、产品思考等等,同时欢迎大家加我个人微信「java_front」一起交流学习

    展开全文
  • 通过把集体讨论确定了优先级的一组场景与效用树中的那组场景进行比较,能发现设计师所想的与项目关系人实际所要的是否存在差距,这一差距是否导致风险。 (8)分析架构方法 类似于第 6 步,这时,评估小组引导设计师...

    软件架构评估是在对架构分析 、 评估的基础上,对架构策略的选取进行决策。它也可以灵活地运用于对软件架构进行评审等工作中。

    1 软件架构评估的方法

    业界已开发出多种软件架构评估的方法,按基于的技术手段来看,可以分为三类:基于调查问卷或检查表的方式 、 基于场景的方式和基于度量的方式。

    (1)基于调查问卷或检查表的方式

    该方式的关键是要设计好问卷或检查表,它充分利用系统相关人员的经验和知识,获得对架构的评估。其缺点是在很大程度上依赖于评估人员的主观推断。

    (2)基于场景的方式

    基于场景的方式由 SEI 首先提出并应用在架构权衡分析法( Architecture Trade off Analysis Method , ATAM )和软件架构分析方法( Software Architecture Analysis Method , SAAM )中。它是通过分析软件架构对场景(也就是对系统的使用或修改活动)的支持程度,从而判断该架构对这一场景所代表的质量需求的满足程度。

    (3)基于度量的方式

    它是建立在软件架构度量的基础上的,涉及三个基本活动,首先需要建立质量属性和度量之间的映射原则,即确定怎样从度量结果推出系统具有什么样的质量属性;然后从软件架构文档中获取度量信息;最后根据映射原则分析推导出系统的质量属性。它能提供更为客观和量化的质量评估,但它对评估人员及其使用的技术有较高的要求。 ATAM 中也使用了度量的思想(度量效用)。

    2 架构的权衡分析法

    从技术角度对软件架构进行评估,旨在通过分析来预见软件的质量;通过分析来创建 、 选择 、 评估与比较不同的架构。例如, Kazman 等人在 2000 年提出的架构的 ATAM 方法。

    ATAM 方法不但能够揭示架构如何满足特定的质量需求(例如,性能和可修改性),而且还提供了分析这些质量需求之间交互作用的方法。使用 ATAM 方法评价一个软件架构的目的是理解架构设计满足系统质量需求的结果。

    ATAM 产生如下结果
    (1)一个简洁的架构表述: ATAM 的一个要求是在一小时内表述架构,这样就得到了一个简洁 、 可理解的 、 面向普通项目关系人的架构表述。它是从架构文档中提炼形成的。
    (2)表述清楚的业务目标。
    (3)用场景集合捕获质量需求。
    (4)架构决策到质量需求的映射。
    (5)所确定的敏感点和权衡点集合:这个集合是一些对一个或多个质量属性具有显着影响的架构决策。如:备份数据库就是这样一个架构决策,它对可靠性产生正面影响,而对系统性能产生负面影响,因此需要进行权衡。
    (6)有风险决策和无风险决策。
    (7)风险主题的集合。找到这些风险主题旨在采取相应的措施。(8)产生一些附属结果。评估过程形成的文档(经受住了评估的考验)可以作为经验保留下来。
    ( 9 )还产生一些无形结果,如能够使项目关系人产生 “ 团队感 ” ,提供了一个交流平台和沟通渠道,使大家更好地理解架构(优势及弱点)。

    ATAM 的 9 个步骤如下:

    (1)ATAM 方法的表述

    评估负责人向参加会议的项目代表介绍 ATAM (简要描述 ATAM 步骤和评估的结果)。

    (2)商业动机的表述

    项目决策者从商业角度介绍系统的概况。

    (3)架构的表述

    对架构进行详略适当的介绍。设计师要描述用来满足需求的架构方法或模式,还应描述技术约束条件及与其他系统的交互等。

    (4)对架构方法进行分类

    通过研究架构文档及倾听上一步的表述,了解系统使用的架构模式和方法(进行明确命名)。

    (5)生成质量属性效用树

    可以选取这样一棵树:根 —— 质量属性 —— 属性求精(细分) —— 场景(叶)。修剪这棵树,保留重要场景(不超过 50 个),再对场景按重要性给定优先级(用 H /M/ L 的形式),再按场景实现的难易度来确定优先级(用 H /M/ L 的形式),这样对所选定的每个场景就有一个优先级对(重要度,难易度),如( H , L )表示该场景重要且易实现。

    (6)分析架构方法

    评估小组按优先级对上述效用树的场景进行分析(小组成员提问,设计师回答 、 解释),探查实现场景的架构方法。评估小组把相关架构决策编成文档,确定其有风险决策 、 无风险决策 、 敏感点 、 权衡点,并对其进行分类(分别用表格列出)。

    (7)集体讨论并确定场景的优先级

    由于项目关系人的不同角色及所关心的场景不一致,因此,应鼓励项目关系人考虑效用树中尚未分析过的场景。集体讨论后,可通过投票的方式获得各场景的优先级。通过把集体讨论确定了优先级的一组场景与效用树中的那组场景进行比较,能发现设计师所想的与项目关系人实际所要的是否存在差距,这一差距是否导致风险。

    (8)分析架构方法

    类似于第 6 步,这时,评估小组引导设计师实现在第 7 步中得到的优先级最高的场景。

    (9)结果的表述

    把在 ATAM 分析中得到的各种信息进行归纳总结,并呈现给项目关 系人。主要有:

    1. 已编写了文档的架构方法;
    2. 经过讨论得到的场景集合及其优先级;
    3. 效用树;
    4. 所发现的有风险决策;
    5. 已编成文档的无风险决策;
    6. 所发现的敏感点和权衡点。

    3 成本效益分析法

    在大型复杂系统中最大的权衡通常必须考虑经济性,因此,需要从经济角度建立成本 、 收益 、 风险和进度等方面软件的 “ 经济 ” 模型。成本效益分析法( the Cost Benefit Analysis Method , CBAM )是在 ATAM 上构建,用来对架构设计决策的成本和收益进行建模,是优化此类决策的一种手段。 CBAM 的思想就是架构策略影响系统的质量属性,反过来这些质量属性又会为系统的项目关系人带来一些收益(称为 “ 效用 ” ), CBAM 协助项目关系人根据其投资回报( ROI )选择架构策略。 CBAM 在 ATAM 结束时开始,它实际上使用了 ATAM 评估的结果。

    CBAM 的步骤如下。

    (1)整理场景。整理 ATAM 中获取的场景,根据商业目标确定这些场景的优先级,并选取优先级最高的 1/3 的场景进行分析。
    (2)对场景进行求精。为每个场景获取最坏情况 、 当前情况 、 期望情况和最好情况的质量属性响应级别。
    (3)确定场景的优先级。项目关系人对场景进行投票,其投票是基于每个场景 “ 所期望的 ” 响应值,根据投票结果和票的权值,生成一个分值(场景的权值)。
    (4)分配效用。对场景的响应级别(最坏情况 、 当前情况 、 期望情况和最好情况)确定效用表。
    (5)架构策略涉及哪些质量属性及响应级别,形成相关的策略 — 场景 — 响应级别的对应关系。
    (6)使用内插法确定 “ 期望的 ” 质量属性响应级别的效用。即根据第4步的效用表以及第5步的对应关系,确定架构策略及其对应场景的效用表。
    (7)计算各架构策略的总收益。根据第3步的场景的权值及第6步的架构策略效用表,计算出架构策略的总收益得分。
    (8)根据受成本限制影响的 ROI ( Return On Investment ,投资报酬率)选择架构策略。根据开发经验估算架构策略的成本,结合第7步的收益,计算出架构策略的 ROI ,按 ROI 排序,从而确定选取策略的优先级。

    展开全文
  • 效用树包含“效用”作为根节点,质量属性构成效用树的辅助级别。 这些属性位于上面表1的第三列。 在每个质量属性下,都会包含特定的质量属性细化,以提供对方案更精确的描述。 后者形成了实用程序树中的叶节点。 ...

    论文题目:Evaluation of two architectures Using the Architecture Tradeoff Analysis Method (ATAM)
    作者:Mildred N. Ambe Frederick Vizeacoumar {mildred, fred}@cs.ualberta.ca
    仅供参考,如有错误欢迎指正。

    摘要

    任何一种软件系统的软件架构都是它的体系结构。 架构决定了系统成功的程度。 因此,找到适当的方法验证任何软件架构以确保整个系统的成功非常重要。 本文使用这种方法之一:体系结构权衡分析方法(ATAM)来评估两种架构。 后者包括Hoover实现的事件架构(第4版)和我们实现的事件架构。 此评估的目标是确定哪个架构能更好地提供系统所需的服务。 本文详细分析了两种体系结构中ATAM的不同阶段。

    1.目的

    本文的主要目标是在两个为事件系统设计的架构上执行ATAM。 我们希望在评估后收集有价值的信息,以回答以下问题:
    •架构是否适合事件系统?
    •两种竞争架构中的哪一种最适合这项任务?
    在ATAM评估步骤完成后,我们将在第7节中提出这些问题的答案。

    2.引言

    系统的体系结构指的是系统的组件和这些组件之间的交互。它提供了对系统的有意义的描述。 “架构允许或排除几乎所有系统的质量属性”[1]。这种质量属性的例子包括可修改性,性能,可靠性等等。上面提到的定义让我们提到了关于软件架构评估的这个事实: “如果架构决策决定了系统的质量属性,那么就可以评估架构决策对这些属性的影响”[1]。现在有很多软件架构技术正在使用,但是这个项目只关注体系结构权衡分析方法(ATAM)。这个项目的目标是使用这种方法来评估两种体系结构:Hoover的最新版本的Event体系结构和我们对后者的实现。这两种体系结构有不同的Event框架实现,它提供’事件服务’。这些服务然后被系统中的事件驱动应用程序组件使用。
    进行架构评估的主要原因是使用ATAM正式确定在提供上述服务方面哪种架构更好。在对每个架构的ATAM阶段进行全面分析之后,我们将有足够的证据对上述事件系统的更好架构做出明智决策。
    本文的结构如下:第三部分介绍了执行软件架构评估的动机。相关的工作部分在第四部分。第五部分简要介绍了主要的ATAM阶段。报告的核心是第六部分,其中ATAM用于评估上述两种体系结构。在第七节中,我们简要讨论前一节的结果,最后的结论在第八节。

    3.动机

    任何系统的体系结构都直接影响系统的成功。因此,架构越好,系统成功实现其创建目标的可能性就越高。然后在开发过程中尽可能早地验证系统的体系结构,以确保其正确运行。
    理想情况下,体系结构评估不应该延迟到体系结构完全确定为止。在系统的早期创建阶段,应该评估架构以确定已经做出的架构决策是否合适,并找出未来决策的可能选项。在这个项目中,正在对两个完全开发的体系结构进行体系结构评估。这不是一个错误的方法,因为评估是一件有用的事情,特别是当给定系统存在竞争架构时。换句话说,在进行架构评估方面迟到比从来没有更好。

    4.相关工作

    目前有许多软件评估技术。 尽管软件评估方法可能由不同阶段构成,但它们有一个共同的目标,即确定体系结构对其预期系统的适用性。
    软件工程研究所开发了三种软件体系结构评估技术:本项目中使用的ATAM,软件体系结构分析方法(SAAM)和中间设计活动评估(ARID)。 尽管这些技术彼此之间有一些相似之处,但每种方法都有一种特有的架构评估方法。 为了节省时间和空间,我们不会停留在任何这些方法上。 我们将严格关注这个项目的ATAM。

    5.ATAM的简要描述

    本节提供了对ATAM各阶段的排除,不包括所有细节。 下面的第6部分提供了关于正在评估的体系结构的ATAM评估阶段的详细描述。
    ATAM根据质量属性要求评估架构决策。 系统中的质量属性对于该系统来说是期望的质量,例如良好的性能,可修改性,安全性等。为了更好地简要介绍ATAM步骤,请参考下图。
    这里写图片描述
    请注意,在下一节中,不同ATAM阶段内的步骤是从第一阶段开始递增的。

    6.使用ATAM评估这两种架构

    阶段1 - 演示(Presentation)

    这是使用ATAM评估软件体系结构的初始阶段。 如上图所示,此阶段有三个主要步骤。 在本文中,我们将重点介绍下面的第三个演示步骤。 这些步骤包括以下内容:

    第1步:介绍ATAM

    这一步涉及ATAM评估过程的描述。在此步骤中,评估负责人向所有相关参与者提供有关ATAM过程的一般信息。领导者解释了评估中使用的分析技术以及评估的预期结果。领导者解决小组成员的任何疑虑,期望或问题。

    第2步:介绍业务驱动因素

    在这一步中,提到了系统体系结构驱动程序的业务目标。这一步着重于系统的业务视角。它提供了有关系统功能,主要利益相关方,业务目标和系统其他限制的更多信息。
    在这一步中,我们将定义被评估系统的主要功能以及涉及的利益相关方。正如引言中所述,本项目中正在评估的体系结构表示应用程序将使用的Event框架。 Event框架的主要功能是处理和处理事件。该任务通过框架中不同现有组件的交互来完成。应用程序组件是利用框架的系统的另一部分。
    利益相关者是在被评估的架构中共享任何形式的利益的人。评估这两种架构时考虑的主要利益相关者包括:最终用户,架构师和应用程序开发人员。这三个利益相关者在两个系统中执行不同的重要任务最终用户通过在命令行界面向系统提供输入来使用“成品”。架构师是事件框架的创建者;而应用程序开发人员负责构建使用事件框架的事件驱动的应用程序。所有利益相关者在系统中都有不同的期望和兴趣。

    第3步:介绍要评估的体系结构

    在这一步中,架构团队描述了要评估的架构。它侧重于体系结构,评估的时间可用性以及所研究体系结构的质量要求。此步骤中的体系结构演示非常重要,因为它会影响分析的质量。本演讲中涉及的一些关键问题是:技术约束,与正在评估的系统交互的其他系统,以及为满足质量属性而实施的架构方法。系统的质量属性是代表系统所需质量的问题。这些属性的例子包括性能,可靠性等。“一个系统的质量属性在很大程度上被其架构所允许或排除”[2]。
    以下是两种体系结构的详细介绍:

    (1)胡佛(Hoover)的事件架构:

    图2显示了Hoover体系结构的简单类图,随后描述了系统及其组件:
    这里写图片描述
    胡佛的架构由组成事件框架的组件和利用框架服务的应用程序组成。 框架组件如下所述。
    如前所述,框架是一个事件框架。 它的命令是事件和这个事件,它们根据它们的类型进行处理。 因此,一个事件由两个主要部分组成:它的类型和事件需要处理的参数。 为了处理多个事件,系统中存在一个事件队列组件。
    事件队列(Event Queue)保存系统中的事件并以先来先服务(FIFO)模式分派它们。 事件队列在任何事件生成任何其他事件时(基于使用此框架的应用程序)特别有用,因为事件需要存储和检索以供将来处理。
    该框架的核心组件是事件管理器(Event manager)。 该组件绑定到事件队列和事件组件。 事件管理器维护事件注册表数据结构,并将事件类型注册到与应用程序相关的关联处理程序中。 可能有多个应用程序处理程序可用。 另外,当事件正在执行时,事件管理器将事件绑定到相应的处理程序。 这是可能的,因为事件管理器维护和事件类型注册表。
    该框架还有一个Handler组件,它是所有处理程序的基类。 基本处理程序组件包含两个主要处理程序:
    • STOP handler - 此处理程序负责系统终止。
    • IDLE handler- 此处理程序执行“空闲等待”,直到用户输入输入事件。 它将系统维持在空闲状态,直到有任何输入被提供给系统处理。
    应用程序在某些定义的“挂钩”处挂钩到上述框架。 如图2所示,灰色背景阴影区域代表了胡佛架构的框架。 主进程控制事件类型和应用程序的状态。 它也控制着事件管理器。 所有应用程序处理程序都会修改系统的状态(在图2中由应用程序处理程序组件旁边的 * 表示)。但是,只有一个事件管理器控制系统。

    (2)“银行”(Banking)事件架构:

    图3显示了一个简单的“银行”体系结构类图,其后是对系统及其组件的描述:
    这里写图片描述
    “银行”体系结构由组成事件框架的组件和利用框架服务的应用程序组成。 框架组件如下所述。
    这个框架与上面描述的Hoover的体系结构类似,但有一些区别。 在这种架构中,即使没有独特的事件组件,底层主题也是一个事件(隐式表示)。 在这种架构中,事件有两个主要部分:类型及其参数。
    事件队列(Event Queue)组件通过排队它们并以FIFO模式返回它们来处理事件的维护。 如果没有要返回的事件,则会生成“空闲”事件。
    有一个基本的Handler组件,它由三个标准的指定处理程序和应用程序处理程序扩展。 该组件包含以下三个标准指定处理程序:
    • START handler - 在启动时初始化系统
    • STOP handler - 终止系统。
    • IDLE handler - 此处理程序执行“空闲等待”,直到用户输入一个输入事件。 它验证输入事件是否有效。 如果有效,则事件排队,否则会产生另一个空闲事件。 该处理程序将系统保持在空闲状态,直到给系统处理任何输入。
    在这个架构中,主模块(Main )是框架的一部分。 该组件绑定到事件管理器和事件队列。 该模块的基本功能是从事件队列中取出一个事件并将其分派给事件管理器进行处理。 该组件中没有应用程序特定的信息。
    在此框架中,应用程序在事件管理器中进行访问。 后者处理绑定事件与事件处理程序的过程。 因此,应用程序被挂接到事件管理器。 应用程序处理程序也链接到此事件管理器,并且此模块中不保留事件注册表存储。 可以有多个可链接到系统的事件和多个链接到从基本处理程序组件派生的事件管理器的应用程序处理程序。 然而在这个框架中只有一个事件队列和一个事件管理器。

    阶段2 - 调查和分析

    这是使用ATAM技术评估架构的第二阶段。 在这个阶段,我们对评估期间要重点关注的一些重要问题进行彻底调查。 这个阶段被细分为三个步骤。

    第4步:确定架构方法

    这一步涉及确定能够理解系统关键需求的关键架构方法。 在这一步中,架构团队解释了架构的流程控制,并提供了关于如何以及是否达到关键目标的适当解释。 以下是与正在评估的两种体系结构有关的两种体系结构方法的讨论。

    (1)胡佛的架构:

    在此体系结构中,系统从闲置处理程序生成的命令提示符处接受输入。输入事件被传递给事件管理器,事件管理器将事件存储在事件队列中。主进程从事件队列中取出事件,并将其分派给事件管理器进行处理。事件管理器然后将事件绑定到其相应的事件处理程序。如果事件未被注册,则事件管理器丢弃该事件并将控制传递给主进程。下一个要处理的事件从事件队列中取出并再次发送给事件管理器。如果没有要处理的事件,则会生成空闲事件,执行空闲等待,直到从系统用户接收到输入为止。如果事件在事件管理器事件注册表中注册,则事件与正确的事件处理程序匹配。该处理程序然后执行该事件,可能导致系统状态的变化。
    从质量属性角度来看结构,可以提出几点。从图2中可以清楚的看出框架之外的应用。每个组件都可以单独出来并重新使用。因此,该架构具有高度的可修改性。另外,这些组件相互适当地进行交互并执行其预期的工作,实现功能的质量属性。架构也可以扩展,因为应用程序构建器可以看到明确的钩子。这涉及到变异性的问题。由于处理在命令行界面输入的无效输入,该系统中的可靠性也得到满足。

    (2)“银行”活动架构:

    在此体系结构中,系统由“开始”事件初始化,该事件在内部生成并处理。从空闲处理程序生成的命令提示符处接收输入。当输入事件输入时,IDLE_Handler检查它的有效性。传递给将事件存储在事件队列中的主模块的有效输入。处理事件时,首先从队列中提取事件并分派给事件管理器进行进一步处理。由于在初始阶段消除了有缺陷的输入,并且事件管理器知道应用程序处理程序,它会将相应的处理程序与事件匹配并执行事件。如果事件队列中没有可处理的事件,则事件队列发送空闲事件。
    关于这个架构中提到的质量属性,可以注意几点。这种体系结构中的一个明显缺陷是,事件管理器组件暴露给应用程序,因此不在框架中(图3中灰色区域之外)。因此可以说,这种架构中没有很好地表现出可修改性。这些组件以协调的方式进行交互,即使它们高度相互依赖。由于组件的相互依赖性,在此体系结构中可重用性不太可能。空闲事件的输入活动需要事件,对其进行解析并消除任何有缺陷的输入,从而实现可靠性问题。

    第5步:生成质量属性效用树。

    在评估的这个阶段,系统的最重要的质量属性目标被确定,确定优先次序和完善。这一步至关重要,因为它将所有利益相关方和评估人员的注意力集中在对体系成功至关重要的体系结构的不同方面。这是通过建立效用树来实现的。
    效用树提供了一种使系统目标更加具体和更具体的方法。它还提供了质量属性目标相对于彼此的重要性的比较。因此,效用树表达了系统的整体“良好”。最重要的是,树包含与系统有关的质量属性,以及对利益相关者重要的质量属性要求。这些要求被称为情景。情景是一个说明利益相关者和系统之间的相互作用的陈述。这些情景是质量目标,体系结构将被判断。
    此阶段完成后,结果将成为ATAM评估步骤其余部分使用的情景优先列表。它缩小了在架构中探索风险或架构方法的地点的选择范围。因此,这一步在评估过程中是非常宝贵的。
    在这个项目中,Event系统有两个相互竞争的体系结构,在这一步中,将会有一个实用程序树代表Event系统的质量目标。这些场景是代表三个利益相关者生成的:最终用户,架构师和应用程序开发人员。如上所述,质量属性需求(场景)在这一步中是非常重要的。经过仔细的思考实验,我们代表利益相关者提出了可能的情景。
    情景生成
    情景生成是创建效用树的前一个重要步骤。下面的表1显示了与每个利益相关者有关的情景以及它所代表的质量属性的启发。
    这里写图片描述
    质量属性效用树生成
    效用树包含“效用”作为根节点,质量属性构成效用树的辅助级别。 这些属性位于上面表1的第三列。 在每个质量属性下,都会包含特定的质量属性细化,以提供对方案更精确的描述。 后者形成了实用程序树中的叶节点。 效用树沿着两个维度排列优先顺序:每个场景对系统成功的重要性以及对此场景实现(从架构师的角度来看)所带来的难度程度的估计。 效用树中的优先级基于相对排名:高(H),中(M)和低(L)。 请参阅图4(下一页)了解实用程序树图。(文中并没有附图……)

    第6步:分析体系结构方法

    这是“调查和分析”阶段的最后一步。在这一步中,我们分析前一步生成的效用树的输出,并进行彻底的调查和分析,找出处理相应质量属性的架构方法。我们根据这些质量属性分析这两种架构,并为它们提供适当的解释。我们还确定每种架构方法的风险,非风险,敏感点和权衡点。
    从步骤5的效用树中,提取高优先级场景。例如,请考虑步骤5中效用程序树中的以下两个方案:
    (L,M)所有操作都以最快的速度处理(性能)
    (H,M)应该处理使用系统中的用户错误(可靠性)
    从场景旁边的(L,M)和(H,M)所示的这些场景的优先级确定,决定选择哪个质量属性。在这个例子中,选择第二种方案是因为它对系统的成功和建筑师的中等难度具有高度重要性。第一种情况不被考虑,因为它对系统的重要性不高。从效用树中获得的高优先级属性是:可变性,可靠性,集成性(Conceptual Integrity),功能性和可修改性。质量属性(如性能,可用性,安全性和可移植性)没有被赋予高优先级,因为它们对系统目标不那么重要(如树中所示)。
    这一步分为四个主要阶段:
    - 调查建筑方法
    - 创建分析问题
    - 分析问题的答案
    - 找出风险,非风险,敏感点,权衡点。

    6.1调查体系结构方法

    在识别出对系统目标很重要的质量属性后,我们分析两种架构并确定它们如何支持这些质量属性。 我们对体系结构进行了详细的调查,以了解这些质量属性要求是否得到满足。
    (a)可变性:
    可变性是定义可以如何扩展或修改架构以生成新体系结构的属性。
    (1)胡佛架构:
    在这个架构中,如图2所示,该框架非常灵活。 Event框架维护一个队列;独立于应用程序的处理程序和事件组件。由于该应用程序未嵌入许多组件,因此该系统具有高度可修改性。例如,如果架构团队希望包含主模块调用队列的新方案,则可以在稍后阶段完成。由于架构清楚地显示了所有组件的交互作用,因此可以重构任何组件,或者可以将任何新组件添加到架构中,而不会影响任何其他组件。因此,胡佛的架构高度支持可变性。
    (2)银行体系结构:
    如图3所示,架构的组件是高度相互依赖的,并且有许多组件包含特定于应用程序的信息。例如,如果主模块调用应用程序处理程序,则事件管理器会受到影响,因为后者包含特定于应用程序的信息。但是,架构的某些部分支持可变性。例如,如果事件队列更改为绑定到事件管理器,而不是当前体系结构中的主模块,则不会影响其他组件。因此,这种架构在一定程度上支持变化。
    另外,这种架构的一个主要缺陷是事件管理器被排除在框架之外,因为它包含与应用程序相关的信息。事件管理器应该是框架内的核心组件。如果这种架构在未来得到扩展,这个缺陷将会造成很大的困难。一般而言,某些组件的更改或新组件的包含很可能会影响其他相关组件。
    (b)可靠性:
    可靠性是决定系统响应故障的行为以及系统如何随时间运行的特性。
    (1)胡佛架构:
    在这个架构中,在输入阶段,任何输入都是在没有消除任何’有缺陷’的输入的情况下处理的。传播有缺陷的输入直到事件绑定时间的主要原因是它是一个特定于应用程序的细节。因此,框架保持不变,无论应用程序是否与之相关。然而,最终在事件管理器组件中以适当的方式处理了有缺陷的输入。因此,该体系结构支持可靠性。
    (2)银行体系结构:
    在此体系结构中,在空闲事件的输入活动中识别有缺陷的输入。因此,在事件存储在队列中之前,将检查类型和参数的有效性(请注意,这是一个特定于应用程序的细节)。尽管这是一个与应用程序相关的活动,但系统在任何有缺陷的输入和可靠性得到满足后都会恢复。但是,如果任何其他应用程序挂钩到框架,则此验证过程必须更改。
    (c)集成性(Conceptual Integrity):
    该属性定义了统一各级系统设计的基础主题。架构应该是一致的,在执行架构的所有进程时使用最少的数据和控制机制。
    (1)胡佛架构:
    在这个架构中,事件在整个系统中以类似的方式处理。无论事件类型如何,主模块都将事件传递给事件管理器,后者将事件绑定到执行该过程的处理程序。在系统中执行任何操作都涉及很少的控制机制,并且后者以有效的方式执行。因此概念完整性得以实现。
    (2)银行体系结构:
    在这个架构中,所有事件都以类似的方式处理,但所使用的控制机制的数量相当高。在这个体系结构中,事件从事件队列中提取并传递给事件管理器,事件管理器相对于某些特定于应用程序的细节处理事件。处理事件后,事件管理器通过调用应用程序处理程序将该事件传播到其处理程序,处理程序依次处理该事件。虽然类似的方法被用于架构中的所有事件,但是使用的控制机制的数量可以被最小化以实现这个目标。因此,在这个架构中,概念完整性的属性没有得到妥善处理。
    (d)功能性:
    此属性标识系统中组件之间的交互,以及系统是否执行预期的任务。
    (1)胡佛架构:
    如前所述,在这个架构中,组件之间展示了适当的相互作用。该体系结构还以有效的方式执行事件处理的预期任务。组件之间的交互是合理和适当的。事件队列保存事件,根据请求分派给事件管理器。另外,事件管理器与应用程序处理程序协调并将事件绑定到相应的处理程序。因此,在这种架构中,功能的属性显然是需要关注的。
    (2)银行体系结构:
    在这种架构中,组件之间存在适当的交互,系统通常适当地执行预期的任务。尽管在系统的许多组件中都嵌入了特定于应用程序的细节,但组件协调也是合理的。因此,在这种架构中适度地解决了功能问题。
    (e)可修改性:
    顾名思义,该属性验证系统是否能够以一种快速,经济高效的方式进行修改。它验证了体系结构如何处理对组件所做的更改,以及是否可以将任何不同的应用程序挂接到框架。
    (1)胡佛架构:
    在此体系结构中,可修改性的程度很高,因为所有框架组件都与应用程序分离。如果要包含任何新的特定于应用程序的组件,该体系结构有能力以经济有效的方式适应这种修改。事件管理器组件维护一个事件类型的注册表,它将每个事件注册到它的处理程序。此注册表的内容不固定,但依赖于使用事件框架的应用程序。这确保了架构中的高度可修改性。
    (2)银行体系结构:
    在这种架构中,应用程序嵌入在许多组件中。因此,重新使用不同应用程序的框架或添加任何新的应用程序特定组件都会涉及很多困难和修改。因此修改过程可能不是成本有效的。鉴于这些观点,这种架构没有表现出足够的可修改性。

    6.2创建分析问题

    本步骤的下一个阶段涉及收集上面讨论过的高优先级场景中产生的分析问题。在现实生活中,所有利益相关者都会收集分析问题。在这个项目中,我们只是简单地创建了优先场景中显著的示例问题。分析问题与上面讨论的每种架构方法相关联;并面向重要的质量属性。以下是分析问题列表和正在解决的属性:
    •架构的组件可以重复用于未来的项目吗? (变化性)
    •未来可以扩展框架以适应新的应用程序或新组件? (变化性)
    •系统会处理用户提供的任何输入并处理无效输入吗? (可靠性)
    •架构的行为是否一致? (概念完整)
    •是否可以将任何新的应用程序特定功能添加到架构中(可修改性)
    •系统能否以短时间和成本效益的方式进行修改?(修改性)
    •组件是否正确交互?(功能性)
    •体系结构是否正确执行其事件处理任务? (功能)

    6.3分析问题的答案

    这一步的第三阶段是根据两种评估架构对上述分析问题提供合理的解释或答案。以下是在每个架构中如何处理这些问题的讨论。
    (1)胡佛架构:
    •架构的组件可以重复用于未来的项目吗?
    如前所述,此体系结构中的每个组件都是相互独立的,并以适当的方式进行协调。例如,无论它链接到哪个组件,事件管理器都会在使用任何注册的事件类型调用时将事件绑定到相应的处理程序。
    •未来可以扩展框架以适应新的应用程序或新组件?
    是的,这个架构可以很容易地扩展以适应更多的组件和任何给定的应用程序。这是由于上一个问题中给出的原因。
    •系统是否处理用户提供的任何输入并处理无效输入?
    虽然有缺陷的输入在稍后阶段被识别,但系统会处理用户给出的所有输入并处理任何无效输入。
    •架构的行为是否一致?
    是的,胡佛的架构在处理所有事件时的行为是一致的。另外,它利用最少数量的控制机制来执行任何给定的任务。
    •是否可以将任何新的特定于应用程序的功能添加到架构中?
    由于应用程序完全独立于此框架组件
    体系结构中,可以将任何新功能添加到架构中,而不会影响其他组件。该应用程序被添加到框架中的’挂钩’,这在这个架构中明确定义。
    •系统是否可以在短时间内以具有成本效益的方式进行修改?
    是的,因为应用程序没有嵌入到许多组件中,并且在极小的地方与框架链接,所以可以在更短的时间内以经济高效的方式进行修改。
    •组件是否正确交互?
    正如上述架构方法的讨论中所解释的,此架构中的组件以协调的方式进行交互。
    •体系结构是否正确执行其事件处理任务?
    胡佛的体系结构提供了所需的结果,因为事件处理的主要任务是通过系统中各组件之间的适当交互来处理的。
    (2)银行体系结构:
    •架构的组件可以重复用于未来的项目吗?
    这些组件可以重用,但会涉及一些重大更改,因为应用程序嵌入了许多组件。但是,像事件队列这样的组件可以被重用。
    •未来可以扩展框架以适应新的应用程序或新组件?
    使用框架来改变应用程序并不是一件容易的事情,因为必须对框架的主要部分进行重大更改。事件管理器组件在此体系结构中是高度特定于应用程序的,并且如果要添加任何应用程序,则必须对其进行修改。出于同样的原因,添加任何新功能都需要付出很大的努力。
    •系统是否处理用户提供的任何输入并处理无效输入?
    是的,系统处理系统用户给出的所有输入并丢弃无效的输入事件。
    •架构的行为是否一致?
    在这种体系结构中,一致性没有充分显示,因为控制权被转移到一系列组件中以执行任何任务。
    •是否可以将任何新的特定于应用程序的功能添加到架构中?
    即使涉及许多组件,也可以向系统添加任何新功能。
    •系统是否可以在短时间内以具有成本效益的方式进行修改?
    鉴于该应用程序嵌入到系统中涉及的许多组件中,所以修改需要更多时间,并且可能不具有成本效益。
    •组件是否正确交互?
    这些组件以适当的方式进行交互(如上面在架构方法讨论中所述)。
    •体系结构是否正确执行其事件处理任务?
    我们的体系结构提供了所需的结果,因为事件处理的主要任务得到处理,即使系统中还存在其他缺陷。

    6.4找出风险,非风险,敏感点,权衡点。

    涉及此步骤的最后阶段是确定风险,无风险,敏感点和权衡点。
    风险是架构中的一个问题点,后者不支持给定的优先级质量属性。 非风险是体系结构的优势,后者实现特定的优先级质量属性。 敏感点是一个或多个组件的属性,对于实现给定的质量属性至关重要。 如果架构对多个属性敏感,那么该点称为权衡点。
    这里写图片描述
    敏感点:
    对于这两种体系结构,以下是敏感点:
    •更改体系结构的范围对应用程序嵌入到系统中的位置数量很敏感。
    •错误输入的处理对应用程序中事件类型的数量很敏感(因为在验证过程中,输入事件是针对已知事件进行验证的)。
    •系统一致性水平对用于处理流程的控制机制的数量很敏感。
    •从系统获取所需输出的过程对组件协调的方式以及彼此之间的交互方式非常敏感。
    •向应用程序添加新功能的能力对应用程序嵌入到系统中的位置数量很敏感。
    权衡点:
    从敏感点可以清楚地看出,应用程序嵌入系统的地方数量会影响变化性和可修改性质量属性。 因此,这形成了一个权衡点。
    基于这一观察,我们发现银行业务体系结构具有上述的权衡点,而胡佛的体系结构则没有。

    阶段3 - 测试

    第7步:头脑风暴和优先场景

    这是ATAM测试阶段的第一步。前者代表利益相关者的利益,用于理解质量属性要求。在效用树生成步骤中,主要结果是从建筑师的角度来理解质量属性。在这一步中,目标是让更大的利益相关者参与其中。该
    将头脑风暴情景的优先列表与在步骤5中从树中获得的优先方案进行比较。利益相关者需要头脑风暴三种场景:
    用例场景 - 在这种情况下,利益相关者就是最终用户。
    增长情景 - 代表了架构发展的方式
    探索性场景 - 代表架构中极端的增长形式。
    在这一步中执行的活动如下:
    首先,情景是在利益相关者的大风暴活动之后收集的。
    场景优先:与相同质量属性有关的所有场景都被合并,利益相关者投票选出他们认为最重要的场景。从[1]中可以看出,每个利益相关者都被分配了一定数量的选票,如下所示:

    票数=场景总数的30%

    投票结束后,投票结果会被记录下来,场景按总票数排序。采取截止线以上的情况,其余不予考虑。
    将优先头脑风暴情景列表与优先情景进行比较
    从步骤5中的效用树中获得。头脑风暴的场景被放置在
    在实用程序树中适当的分支。它可能是树中已经存在的场景的副本,或者它可能在新的叶子下,或者可能不适合任何分支。
    在这个阶段提及这一点很重要,因为我们正在进行两次ATAM
    一个项目中的体系结构,我们只能模拟利益相关者,他们的想法和他们的兴趣。这个阶段有一些步骤,在现实生活中有很多利益相关者,评估团队,建筑师和开发人员,这些步骤更加明智。在这个项目中,我们尽可能地尝试来表示这个过程的不同部分。
    我们首先介绍这一步中的头脑风暴情景列表,为我们正在评估的架构中的三个利益相关者。场景列表不需要与步骤5中生成的场景不同,但也可以通过头脑风暴过程生成新场景。下面的表3显示了编号方案的列表,方案的类型以及它所代表的质量属性。
    这里写图片描述
    在这一点上,头脑风暴的场景清单已经准备就绪。 下一步是让利益相关者为他们认为重要的情景进行投票。 分配给每个利益相关者的票数定义如下:
    票数= 30% (情景总数)= 0.3 16(到最近的整数)= 5

    因此,三个利益相关者每个都有5张投票可供选择。 接下来,我们模仿一个投票活动,每个利益相关者对与他们最感兴趣的情景进行投票。 在这个阶段,我们根据不同的利益相关者进行思考,并对各种情况进行投票。 示例投票活动的结果显示在下面的表4中(所有得到总共0张选票的情况均不包含在此表中):
    这里写图片描述
    这里写图片描述

    第8步:分析架构方法

    这是“测试”阶段的最后一步。在这一步中,我们分析上一步中高质量的质量属性。我们找到了处理这些质量属性的架构方法,并检查架构是否支持这些属性。这一步重复“调查和分析”阶段的第6步。唯一的区别在于,在步骤6中,高优先级质量属性来自效用树,而这一步需要高度投票的头脑风暴质量属性。一些来自步骤6的优先级质量属性可能在这里重新发生,而一些新的可能会出现。最后,分析优先方案的风险,非风险,敏感点和权衡点。
    从上一步的投票表中,高质量的质量属性是:功能性,可靠性,可修改性,安全性,性能和可变性。由于其中一些质量属性已经在步骤6中讨论过,所以我们只关注新出现的属于安全和性能质量属性的情况。在这一步中,仅根据这两种情况分析两种体系结构。
    这一步分为四个主要阶段:
    - 调查建筑方法
    - 创建分析问题
    - 分析问题的答案
    - 找出风险,非风险,敏感点,权衡点。

    8.1调查建筑方法

    (a)安全性:
    此属性验证系统是否有能力限制未经授权的访问,以及体系结构是否提供任何数据机密性。
    (1)胡佛架构:
    在这种架构中,一些组件以适当的方式使用数据封装。例如,只有事件管理器执行事件注册表活动,因此未经授权的组件不能执行此任务,或者操作事件注册表数据结构。由于框架完全独立于特定于应用程序的信息,因此组件的协调确保正确的数据封装,并且信息仅对需要它的组件可见。因此,解决了安全问题。
    (2)银行体系结构:
    在这种体系结构中,特定于应用程序的信息被嵌入到架构中的许多组件中,因此数据机密性处理不当。因此,框架的结构非常“开放”。但是,在某些情况下,保密性是可以达到的。例如,应用程序处理程序仅由事件管理器调用,并且不能由其他组件访问。这支持一些受限组件的安全性,但不支持整体体系结构。
    (b)性能:
    该属性使我们能够了解系统的响应性。性能因素通常表示为每单位时间的交易次数或执行一次交易所花费的时间。
    (1)胡佛架构:
    在此体系结构中,用户界面是命令驱动的,因此整个系统的性能不能以每单位时间的事务数量来衡量。但是,由于执行任何给定流程所涉及的组件都很少,我们可以推断执行一项事务所花费的时间很少。因此,该体系结构解决了性能问题。
    (2)银行体系结构:
    这种体系结构也是由命令驱动的,并且如果根据处理任何事件所涉及的组件数量来计算性能,则可以说该体系结构中的这个数字更高。因此,这种体系结构中的性能不足。

    8.2创建分析问题

    以下是利益相关方收集的分析问题清单,并基于高度投票的情景。
    •系统是否允许未经授权的访问? (安全)
    •架构是否描绘数据机密性? (安全)
    •架构是否以最快的速度处理任何任务? (性能)

    8.3分析问题的答案

    现在我们在这两种体系结构中找到这些分析问题的合理答案。
    (1)胡佛架构:
    •系统是否允许未经授权的访问?
    在组件层面,胡佛的架构中未经授权的访问受到限制。但是,在应用程序级别,如果需要,可以通过修改应用程序组件来限制访问。
    •架构是否描绘数据机密性?
    如前所述,特定于应用程序的信息并未嵌入组件的许多部分,因此数据得到了很好的保护。
    •架构是否以最快的速度处理任何任务?
    由于执行任何任务所涉及的组件数量极少,并且每个组件中的处理量在此架构中最小,因此后者以最快的速度执行操作。
    (2)银行体系结构:
    •系统是否允许未经授权的访问?
    在组件级别,某些组件受到限制,而体系结构中的大多数组件都可用于访问未经授权的组件。
    •架构是否描绘数据机密性?
    考虑到应用程序特定的信息在许多组件中可用,这些信息分散在架构中,因此不存在数据机密性。
    •架构是否以最快的速度处理任何任务?
    由于涉及事件处理的组件数量很多,因此此架构不能以最快的速度执行操作。

    8.4找出风险,无风险,敏感点,权衡点。

    风险与无风险:
    这里写图片描述
    敏感点:
    •数据保密级别对嵌入应用程序的地点数量很敏感。
    •执行任务的平均速度对处理任务所涉及的组件数量敏感。
    权衡点:
    考虑到上述敏感点和步骤6中列出的敏感点,我们得出以下权衡点。
    •应用程序嵌入的地点数量
    •处理任务所涉及的组件数量
    基于这些权衡点,我们可以推断Hoover的架构在框架中没有应用程序特定信息,并且执行任务所涉及的组件数量很少,而在银行架构中,这两个权衡点都不被处理正确。

    阶段4 - 报告ATAM

    这是ATAM评估的最后阶段,其中提供了评估期间收集的所有信息。 ATAM团队将他们的发现呈现给利益相关者群体。
    ATAM团队的主要发现通常包括:
    - 一种效用树
    - 一组生成的场景
    - 一组分析问题
    - 一套确定的风险和非风险
    - 确定的建筑方法
    鉴于通过这份报告我们已经介绍了这些发现,这个阶段是多余的。

    7.从ATAM评估观察

    在使用ATAM技术评估这两种架构之后,我们发现了许多有趣的结果。 ATAM评估的主要目标是为开发系统确定更好的体系结构。如表2和表6所示,其中包含两种架构的风险和非风险,我们发现Hoover的架构没有任何风险,而银行架构则有三种风险。
    同样,第8步(测试阶段)的结果显示,银行架构中存在两个权衡点,而胡佛架构中没有权衡点。
    因此,在这个时刻,考虑到从ATAM评估中获得的所有输出,我们有足够的证据从架构角度证明Hoover的架构最适合它所设计的基于事件的系统。另一方面,可以改进银行业务体系结构以更好地满足系统的需求,但讨论如何实现这一点超出了本项目的范围。

    8.结束语

    这个项目的目标是使用ATAM来评估2个已经开发的架构。 使用ATAM非常有趣,因为评估过程提出了每个体系结构中不一定很明显的关键部分。 尽管“测试”阶段与“调查和分析”阶段几乎完全相同,但确保过程彻底,并且利益相关者的观点受到高度重视。
    在现实生活中,由于上述原因,ATAM将成为一种很好的评估技术。 在这个项目中,我们必须考虑系统的三个利益相关者,并进行思考实验以实施一些ATAM步骤。
    一般来说,从事这个项目的工作对软件体系结构评估,质量属性要求以及所有利益相关者参与系统评估的重要性有一定的了解。

    参考文献:

    [1] Paul Clements, Rick Kazman and Mark Klein, “Evaluating Software Architectures: Methods and Case Studies”, SEI Series in Software Engineering.
    [2] “Software Architecture Evaluation: A Key to System Success”, http://interactive.sei.cmu.edu
    [3] Dr. James Hoover, “Hoover’s Architecture Version 4”.

    展开全文
  • 在架构评估过程中,质量属性效用树(utility tree)是对系统质量属性进行识别和优先级排序的重要工具。请给出合适的质量属性,填入图1-1中(1)、(2)空白处;并选择题干描述中的(a)~(o),将恰当的序号填入(3...
  • 系统在图形用户界面上将构件库的关键字形结构直观地展示给用户,复用者通过对形结构的逐级浏览,寻找需要的关键字并提取相应的构件。当然,复用者也可以直接给出关键字(其中可含通配符),由系统自动给出合适的...
  • 阐述理由(10’) 第六题 实验题 从实验做的四个项目中选择一个回答问题(35’) 1、项目背景 2、质量属性优先级和画两个质量场景图 3、ADD设计方法并进行第一步分解 4、生成质量属性效用树 5、选一个属性进行战术评审...
  • 1.软件质量属性 系统架构评估中普遍关注的质量属性: 性能,它是指系统的响应能力,即需要多长时间才能对某个事件做出响应,或者在某段时间内系统所能处理的事件个数。 可靠性,它是软件系统在应用或者系统错误面前...
  • 软件体系结构复习资料

    千次阅读 2019-01-11 21:49:48
    生成质量效用树   确定系统最重要的质量属性目标,对这些质量属性进行优先级排序  6. 分析架构方法   可以对每一个架构分析,完成该方法相关质量属性的初步分析,得到一个方法,或者风格的列表,(风险,敏感点...
  • 质量属性效用树主要关注性能、可用性、安全性和可修改性。 1.软件质量属性   《GB/T16260-1996(idt ISO/IEC9126:1991)信息技术软件产品评价质量特性及其使用指南》中描述的软件质量特性包括功能性、可靠性、...
  • 写在前面,考后回忆,仅供参考!!! 重点复习老师的PPT,复习要细致和架构设计和评审实验...4.生成质量属性效用树 5.选一个属性进行战术评审 七 12306有哪些架构模式和战术有利于购票?你能给出什么改进建议?
  • 软考系统架构师笔记-最后知识点总结(三)

    千次阅读 多人点赞 2019-10-29 09:30:55
    ATAM中文名:体系结构权衡分析方法,他最后的目标是生成关键的质量属性效用树。 在软考中,体系结构=架构 体系结构权衡方法(ATAM)包含4个主要的领域活动:场景和需求收集、体系结构视图和场景实现、属性模型构造...
  • 软件构架实践(第2版)学习笔记

    万次阅读 2009-11-03 22:17:00
    生成质量属性效用树,捕获详细的需求信息,为每个场景分配一个级别,如(高,中),前者为重要度,后者为实现难易度,重点放在(高,高)的场景;此处场景具备刺激、环境、响应三要素就可以了。 第 6 步:分析...
  • 《软件架构评估》读书笔记

    千次阅读 2011-11-19 17:45:55
    在对场景进行集体讨论的过程和设置优先级的过程中,有很多风险承担者参与其中,与最初的效用树相比,两 者之间的不匹配可以揭露架构设计师未曾注意到的方面,从而使得我们发现架构中的重大风险。 由所有风险...
  • 软件构架的评估方法:ATAM

    千次阅读 热门讨论 2016-11-13 21:31:16
    5) 生成质量属性效用树,捕获详细的需求信息,为每个场景分配一个级别,如(高,中),前者为重要度,后者为实现难易度,重点放在(高,高)的场景;此处场景具备刺激、环境、响应三要素就可以了; 6) 评估...
  • 开发机器学习应用程序的步骤 (1) 收集数据 我们可以使用很多方法收集样本数据,如:制作网络爬虫从网站上抽取数据、从RSS反馈或者API中得到信息、设备发送过来的实测数据(风速、血糖等)。提取数据的方法非常多,...
  • 在这个例子里,边际效用递减法是说,在超过一定消费量后(谷物超过一袋后),消費者從新增加的一單位消费品中得到的效用要比前一个单位为少(第二袋谷物比第一袋谷物效用少,第三袋又比第二袋更少等等。) ...
  • 二话不说,先上代码 import torch class HMM(object): def __init__(self, N, M): """Args: N: 状态数,这里对应存在的标注的种类 M: 观测数,这里对应有多少不同的字 ... # 状态转移概率矩阵 A[i][j]表示从i...
  • 这个项目是一个springboot的简单实用demo,主要包括了springboot中静态资源的配置和控制器的实现。 项目结构 实用的工具是idea,并且用maven构建项目 静态资源配置 ...在springboot中静态资源一般都放在resources...
  • 效用分数调查用于估计与成功手术,附加切缘切除术和术后并发症相关的质量调整生命年(QALYs)。 开发了决策分析以突出更具成本效益的策略。 计算了增量成本-效用比(ICUR)。 进行敏感性分析以检查我们数据的...
  • 详解微服务架构

    2020-03-01 21:09:34
    在微服务架构中,一个服务故障可能会产生雪崩效用,导致整个系统故障。其实在节前,小明和小红是有做过请求量评估的。按照预计,服务器资源是足以支持节日的请求量的,所以肯定是哪里出了问题。不过形势紧急,随着每...
  • linux常用命令

    千次阅读 多人点赞 2016-12-22 11:24:58
    要通过以1024字节为单位显示一个目录及其每个子树的磁盘使用情况 du -k /home/linux 这在/home/linux目录及其每个子目录中显示了 1024 字节磁盘块数。 3> 以MB为单位显示一个目录及其每个子树的磁盘...
  • 我相信如果之前没有对贝叶斯有很深刻的了解,这个视频绝对会对大家有所帮助 【运筹学】基础教程(已完结){适用范围:本科、考研、考博}_哔哩哔哩_bilibili 效用曲线与决策 效用函数 一般来说对于投入,就会得到一...
  • 系统:图书管理系统 框架:SSH框架 主创人员:张欢龙  此篇博文是基于上一篇博文而来,深一层次谈谈系统开发的质量属性。首先先来明确一下“质量属相”是什么?一个系统的好坏有两个方面决定一方面是系统的...
  • 该方法首先为决策目标建立一棵与决策目标相关的属性,并通过决策会议将决策简化,然后为简化后的决策的重要属性建立效用函数,使用RR、RS、ROC以及权衡方法确定各属性权重,并计算出各备选方案的效用值,从而...
  • 1. 简述什么是人工智能   人工智能可分为两个...2. 考虑一个医疗诊断系统的agent,讨论该agent最合适的种类(简单agent,基于模型的agent,基于目标的agent和基于效用的agent)并解释你的结论   我认为基于效用的agen
  • 如果它是一棵,如果它在不与编辑软件进行任何互动的情况下在四季中循环,会怎样?"吉尔伯特森补充说。 当数字资产有了自己的生命,并开始模仿现实世界资产的特征时,事情就开始变得令人振奋。人工智能和游戏引擎...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 4,420
精华内容 1,768
关键字:

效用树