软件设计师教程综合知识集锦(五).docVIP

软件设计师教程综合知识集锦（五） 2017上半年软考软件设计师考试将于5月20日进行，同学们要开始备考了哦，希赛小编为打算参加上半年考试的你们准备了一些软件设计师教程综合知识集锦，希望对大家有所帮助。 SOA方法学和其他方法学的比较 广义上讲，SOA方法学贯穿于IT生命周期的各个阶段和各个方面：IT系统项目的规划，系统分析和设计，系统的实施，系统的部署和维护，以及整个过程中的监控和管理等。从实践的角度说，已经出现如下SOA方法学。 (1)面向服务的分析和设计(SOAD)。以服务为中心，根据业务需求发现服务、描述服务，并设计服务的实现。 (2)面向服务的开发过程。结合现有开发过程，规划以服务为中心的开发过程中的角色、职责、活动和工件。 (3)SOA的成熟度分析和迁移路线图。以服务为中心，分析现有或目标系统的成熟度，并设计从现有成熟度迁移到目标成熟度的路线图。 (4)SOA监管。设计组织和流程，确保SOA的设计原则在IT生命周期中得以贯彻，管理服务生命周期中的各种迁移的合理性等。 本章对SOA方法学的阐述主要集中在面向服务的分析和设计。首先介绍SOA方法学和主要的几种方法学的区别和联系，其次以IBM的SOMA(Service Oriented Modeling and Architecture，面向服务的建模与架构)为例，介绍SOA分析和设计中的主要内容和方法。 与SOA的设计原则类似，SOA方法学并不是全新的方法学，它是现有方法学的继承和发展。一方面，原有的方法学并不能解决由于服务概念的引入带来的问题，如怎样发现服务，怎样定义服务;另一方面，服务是一个水平的概念，而不是一个垂直的概念，在服务分析和设计的过程中，需要处理服务和现有方法学产物的关系，如业务流程和服务，企业架构和SOA，服务和对象等。因此服务的分析和设计最主要的职责在于发现服务、定义服务和实现服务，并指导如何和其他方法学结合完成这些职责。 流程建模(BPM)用于业务领域的分析和设计，如业务流程的定义、业务数据的定义等;企业架构(EA)和方案架构(SA)侧重在架构领域的分析和设计，如根据业务需求确定目前目标业务系统和IT系统，根据目标系统需求设计主要架构元素和它们之间的关系;面向对象的分析和设计(OOAD)则贯穿分析、设计和开发三个阶段，它主要分析细粒度的业务需求，如用例，分析和设计实现这些需求的类和对象，以及它们之间的关系。 1.BPM和SOA 业务流程建模是一个相当零散的领域，存在各种各样的方法和技术，有效的方法可以帮助企业对业务进行合理的划分，从而求得业务层面的灵活性。有些方法则侧重于流程建模本身，例如如何确定和定义业务流程中的业务活动、业务数据、业务规则、业务指标和业务事件等，但是BPM并不会帮助我们去发现和定义服务。从SOA的方法学来看，各种BPM的结果是面向服务的分析和设计的重要输入，如业务组件、业务流程和业务目标是服务发现的重要依据，而业务指标、业务数据、业务规则等是服务暴露的分析的重要依据。 2.EA和SOA 尽管和BPM一样，EA是一个零散的领域，但是当前的EA主要侧重于定义跨越业务单元边界的系统框架，企业范围内系统的主要构成元素，这些元素间的关系，以及将这些元素有机组合在一起的参考架构。但是，各种EA技术都缺乏业务领域的蓝图指导企业架构的设计。从SOA方法学来看，一方面，面向服务的分析和设计通过和BPM结合将业务分解为各种类型的服务，可以作为企业业务的蓝图指导企业架构的设计;另一方面，企业架构设计的结果，如参考架构，又是服务实现的重要依据。 3.OOAD和SOA 面向对象的分析和设计告诉我们使用Use Case捕获需求，并设计类、对象及对象间交互来满足Use Case定义的需求。但是面向对象的分析和设计往往只是局限在单个应用内部，它不会缺乏业务蓝图和企业架构蓝图的指导。从SOA方法学看，在原理层面上，OOAD中的很多设计原则，如抽象、隔离关注等被SOA继承和发扬，并应用于服务的定义和实现中。而在操作层面上，服务模型为OOAD进行类和对象设计提供了业务蓝图和企业架构蓝图，与此同时，Use Case作为对业务流程的补充说明被用于服务的发现和定义中。 SharePoint工作流开发 一直以来都被MOSS的工作流权限问题所困扰. 我们虽然将任务分配给了某人,但事实上,所有在任务列表中有编辑权限的用户都可以编辑该任务. 而我们并不希望用户能够看到不属于自己的任务. 我曾经尝试过采用以下两种方法解决这一问题,未果. 1.更改任务列表的视图. 通常我们会把工作流任务分配给某人或者某组,所以我的想法是将任务列表的我的任务视图和按我的用户组视图合并为一个新的所有我的任务视图; 设置所有我的任务视图为默认视图; 删除其余视图; 取消用户创建视图的权限; 看起来不错,但是