会员登录
会员注册
4.三个抽象级
从概念上讲，SOA 中有三个主要的抽象级别：
·操作：代表单个逻辑工作单元(LUW)的事务。执行操作通常会导致读、写或修改一个或多个持久性数据。SOA 操作可以直接与面向对象 (OO) 的方法相比。它们都有特定的结构化接口，并且返回结构化的响应。完全同方法一样，特定操作的执行可能涉及调用附加的操作。
·服务：代表操作的逻辑分组。服务可以分层，以降低耦合度和复杂性。一个服务的粒度(granularity)大小也与系统的性能息息相关。粒度太小，会增加服务间互操作通讯的开销;粒度太大，又会影响服务面对需求变化的敏捷性。
·业务流程：为实现特定业务目标而执行的一组长期运行的动作或活动。业务流程通常包括多个业务调用。
在SOA中，业务流程包括依据一组业务规则按照有序序列执行的一系列操作。操作的排序、选择和执行称为服务或流程编排。典型的情况是调用已编排服务来响应业务事件。从建模的观点来看，由此带来的挑战是如何描述设计良好的操作、服务和流程抽象的特征以及如何系统地构造它们。这些涉及服务建模、特征抽取的问题已经成为现阶段人们关注的焦点。
三、建立一套行之有效的，在项目启动阶段就应该得到客户认可的需求管理制度
对变更的内容进行严格的控制实施需求变更管理需要遵循如下原则：
1.建立需求基线。需求基线是需求变更的依据。在开发过程中，需求确定并经过评审后(用户参与评审)，可以建立第一个需求基线。此后每次变更并经过评审后，都要重新确定新的需求基线。
2..制订简单、有效的变更控制流程，并形成文档。在建立了需求基线后提出的所有变更都必须遵循这个控制流程进行控制。同时，这个流程具有一定的普遍性，对以后的项目开发和其他项目都有借鉴作用。
3.成立项目变更控制委员会(CCB)或相关职能的类似组织，负责裁定接受哪些变更。CCB由项目所涉及的多方人员共同组成，应该包括用户方和开发方的决策人员在内。
4.需求变更一定要先申请然后再评估，最后经过与变更大小相当级别的评审确认。
5.需求变更后，受影响的软件计划、产品、活动都要进行相应的变更，以保持和更新的需求一致。
6.妥善保存变更产生的相关文档。
需求变更既然不可避免，那么就必须有一套规范的处理流程。对于需求变更的处理流程应该分以下步骤：提出变更à变更评估à实施变更。
需求变更处理流程
因为现实世界的软件系统可能有不同的严格程度和复杂性，所以事先预言所有的相关需求是不可能的。系统原计划的操作环境会改变，用户的需求会改变，甚至系统的角色也有可能改变。实现和测试系统的行为可能导致对正解决的问题产生新的理解和洞察，这种新的认识就有可能导致需求变更。CMM提出“分配需求的变更被复审，并加入到软件项目中来”，其关键是在需求发生变更时，没有必要马上把这些变更付诸于软件开发工作之中。实际上，坚持把需求变更付诸开发努力，企业就会形成一种混乱且不稳定的氛围，进而严重破坏项目的控制和管理。需求管理关键过程试图通过把分配需求的变更囤积到可管理的组中，等到开发工作允许的时候再引人相应的方法，避免产生这种混乱的氛围。结果，需求管理创建了一个隔绝开发工作与所有真实的、潜在无序的、来自于客户的变更。这个缓冲器允许真实的变更被注意、记录、追踪，同时开发工作又不会因此而被扰乱。开发项目应该周期性地暂停来吸收最新的需求变更积累，此时，所有的计划、设计、行为都根据刚刚吸收的需求变更的影响进行更新。
需求变更的控制当然与项目管理范畴之外的纯技术因素息息相关，比如面向对象的分析、面向对象的设计、面向对象的编码方式等等。但所有技术的发展趋势都是一样，那就是为了使变更管理变得更容易，因此，不论在项目变更控制中采取什么方法、策略，对于项目本身的变化一定要时时洞悉，处处留意，只有这样才能从真正意义上对项目进行很好的变更控制。