问题域

IEEE对需求定义为：①用户为了解决问题或达到某些目标所需要的条件或能力。②系统或系统部件为了满足合同、标准、规范或其他正式文档所规定的要求而需要具备的条件或能力。③对①或②中的一个条件或一种能力的一种文档化表述。通过这个定义了解了需求并不是用户想要的，想实现的，了解了需求本质的内涵。 功能需求是软件系统需求中最常见、最主要和最重要的需求，同时也是最为复杂的需求。功能需求通常体现为三个层次：业务需求、用户需求、系统需求。 业务需求描述了组织为什么要开发系统，满足用户的业务需求。业务需求是用户需要在业务上使自己更加方便的开展工作的需求。 用户需求表达了用户对系统的期望，但是要透彻和全面地了解用户的真正意图，仅仅拥有期望是不够的，还需要期望的背景知识。因此，对所有的用户需求，都应该有充分的问题域知识作为背景支持。而在实际工作中，用户表达自己的期望时，通常不会提及需求所涉及问题域知识，所以需求工程需要根据用户的需求整理完整的问题域知识。 系统需求是用户对系统行为的期望，一系列的需求联系在一起可以帮助用户完成任务，达到用户需求，进而满足业务需求。需求工程可以直接映射为系统行为，定义了系统中需要实现的功能，描述了开发人员需要实现什么。 将用户需求转化为系统需求的过程，在该过程中，首先需要分析问题领域的特性，从中发现问题域和计算机系统的共享知识，建立系统的知识模型

IEEE对需求定义为：①用户为了解决问题或达到某些目标所需要的条件或能力。②系统或系统部件为了满足合同、标准、规范或其他正式文档所规定的要求而需要具备的条件或能力。③对①或②中的一个条件或一种能力的一种文档化表述。通过这个定义了解了需求并不是用户想要的，想实现的，了解了需求本质的内涵。 功能需求是软件系统需求中最常见、最主要和最重要的需求，同时也是最为复杂的需求。功能需求通常体现为三个层次：业务需求、用户需求、系统需求。 业务需求描述了组织为什么要开发系统，满足用户的业务需求。业务需求是用户需要在业务上使自己更加方便的开展工作的需求。 用户需求表达了用户对系统的期望，但是要透彻和全面地了解用户的真正意图，仅仅拥有期望是不够的，还需要期望的背景知识。因此，对所有的用户需求，都应该有充分的问题域知识作为背景支持。而在实际工作中，用户表达自己的期望时，通常不会提及需求所涉及问题域知识，所以需求工程需要根据用户的需求整理完整的问题域知识。 系统需求是用户对系统行为的期望，一系列的需求联系在一起可以帮助用户完成任务，达到用户需求，进而满足业务需求。需求工程可以直接映射为系统行为，定义了系统中需要实现的功能，描述了开发人员需要实现什么。 将用户需求转化为系统需求的过程，在该过程中，首先需要分析问题领域的特性，从中发现问题域和计算机系统的共享知识，建立系统的知识模型

笔记要求：发表一篇阅读笔记，说明本学期《软件需求分析》需要掌握哪些必要的内容？针对每个内容点说出自己的理解，并绘图示意相互之间的关联关系。 　　　　　　　　　 　读《需求工程——软件建模与分析》有感 　　 今天大致的看了一下这本书，对软件需求分析有了初步的了解，我认为学习软件需求分析需要掌握的内容主要包括五个方面：需求基础与过程、需求获取、需求分析、需求的文档化和验证、需求管理与工程管理。 　　 一、需求的基础与过程 　　这一部分主要是对软件需求有一个大致的了解，例如需求的概念，不同群体的人们对需求有不同的理解，IEEE对需求的定义：用户为了解决问题或达到某些目标所需要的条件和能力；系统或系统部件为了满足合同、标准、规范或其他正式文档所规定的需求而需要具备的条件或能力。 　　软件系统通过影响问题域，能够帮助人们解决问题，成为解系统。解系统是问题的解决手段，但是并不是问题的产生地。所以，解系统并不是问题域的一个部分，它们之间存在可以相互影响的接口，以实现交互活动。 　　功能需求被分为：业务需求、用户需求、系统需求。三者之间有所区别，将用户需求转化为系统需求是一个复杂的过程。 　　需求工程的过程就是：需求获取、需求分析、需求规格说明、需求验证、需求管理的过程。 　　 二、需求获取 　　 顾名思义，需求获取就是进行需求收集的一个活动，他从人员、资料和环境中得到的系统开发所需要的相关信息。

一、了解什么是面向对象的软件开发方法 答：1、OOSD是一种把面向对象的思想应用于软件开发过程，是一种当今成熟的、普遍流行的软件开发方法 2、面向对象方法的解决思路是从现实世界中的客观对象入手，尽量运用人类的自然思维方式来构造软件系统。是一种运用对象、类、继承、封装、聚合、消息传送、多态性等概念来构造系统的软件开发方法。 3、面向对象方法中，把一切都看成是对象。对象是功能抽象和数据抽象的统一，较过程稳定。 二、面向对象软件开发的主要思想 答：1、按照人类的自然思维的方式，对客观世界建立软件模型。 2、客观实体和实体之间的联系构成了现实世界的所有问题。 3、面向对象技术将现实世界中的实体及相互关系映射为对象及对象间的关系，实体间的相互作用被映射为对象间的消息发送等。 三、面向对象方法的主要优点 答：（1）把易变的数据结构和部分功能封装在对象内并加以隐藏 i、保证了对象行为的可靠性。 ii、对其修改并不会影响其它对象，有利于维护，对需求变化有较强的适应。 （2）封装性和继承性有利于复用对象 i、把对象的属性和操作捆绑在一起，提高了对象（作为模块）的内聚性，减少了与其它对象的耦合，为复用对象提供了可能性和方便性。（高内聚，低耦合） ii、在继承结构中，特殊类对一般类的继承，本身就是对一般类的属性和操作的复用。 四、面向对象开发方法的组成 答：（1）OOA（Object-Oriented

转载： http://www.uml.org.cn/oobject/201210081.asp 三者描述对象的 附属[也就是依赖]关系 : 关联 < 聚合 < 组合，依赖关系是逐渐加强的。 inheritance: "a kind of": 猫是一种动物，说明猫从动物继承； association: 两者之间存在某种关联即可，很弱的关系，如student and course, 每个学生可以选不同的课，每门课上有不同学生； aggregation: "consist of"：整体与部分之间的关系，但这里部分可以脱离整体单独存在，如MP3上所插的耳机，MP3包含耳机，但这个耳机也可以单独存在，或者插在其他电脑上。 composition: 更强的aggregation，这里部分不能脱离整体而存在，这个部分是整体的私有财产。比如Apple Itouch上的电池，原则不能拆下来单独使用。 1、关联 双向关联： C1-C2：指双方都知道对方的存在，都可以调用对方的公共属性和方法。 在GOF的设计模式书上是这样描述的：虽然在分析阶段这种关系是适用的，但我们觉得它对于描述设计模式内的类关系来说显得太抽象了，因为在设计阶段关联关系必须被映射为对象引用或指针。对象引用本身就是有向的，更适合表达我们所讨论的那种关系。所以这种关系在设计的时候比较少用到，关联一般都是有向的。 关联

需求工程复习 1.2.1需求工程简介 定义 简单地说，需求工程是所有需求处理活动的总和，它收集信息，分析问题，整合观点，记录需求并验证其正确性 从细节上说，需求工程是软件工程的一个分支，它关注软件系统所应实现的现实目标，软件系统的功能和软件系统应当遵守的规约 3个任务： 必须说明软件系统将应用的环境与目标，‘“做什么”，“怎么做” 必须将目标，功能，约束反映到系统软件中 妥善处理目标，功能和约束随着时间的演化 基本活动 需求工程分为 需求开发 与 需求管理 需求管理 ：需求管理是对需求开发所建立的需求基线的管理。它在需求基线完成后正式开始，在需求工程结束之后继续存在 需求开发 需求获取：从项目战略规划开始建立的最初原始需求 需求分析：保证需求的 完整性 与 统一性 需求规格说明：将完整性，一致性的需求与能够满足需求的软件行为以文档方式明确固定下来 需求验证：保证需求及其文档的 正确性 ， 完整性 与 一致性 ，最后统一意见，得出需求规格文档 2.2.2 问题与与解系统 问题域与解系统的关系 问题域：是需求的背景，解决问题必须涉及的事件和事物，即解决问题的基本范围（用户关注的问题） 解系统：指的是软件系统，软件系统通过影响问题域帮助人们解决问题，是软件解决方案在计算机上的实现（开发人员关注的问题） 关系：两者通过接口连接起来，这个接口就是**(模拟性)共享对象**

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 对于软件开发来说，领域建模是最重要的活动，领域模型是最重要的产物。领域模型反映了软件所要服务的现实业务领域的本质，体现了我们对业务领域的认识、理解和洞见。 领域模型应该是一切领域开发活动的出发点和依归。 本系列文章以组织结构的领域建模为例，演示领域建模的方法和技巧。 领域模型的重要性 领域模型的重要性体现在： 领域模型的正确性决定了软件在业务上的正确性。 领域模型代表我们对问题域——即软件所要服务的现实业务领域——的组成、结构、行为、机制和规则的认识和理解。模型错误就是对问题域的认识错误，根据错误的模型开发出来的软件（解决方案）必然错漏百出，不符合业务需要。正如同解数学题，如果我们对试题的理解是错误的，我们给出的答案必然是错的。正如同赛跑，如果方向错误了，跑得快是没有什么用的。高超的设计思想和编码技巧都无法弥补领域模型的缺陷。 领域模型的抽象性决定了软件在未来业务上的扩展性。 我们知道在问题域中，既存在共性，也存在个性。好的领域模型通过抽象和分解等等方式，既实现了共性，也使个性化成为可能。不好的领域模型，或者无法进行个性化扩展，或者扩展的成本很高，需要对系统进行伤筋动骨的改动。 好的领域模型既满足当前客户的需要，也支持相同领域其他客户的需要；既符合当前业务需要，也支持未来业务扩展的需要

本文探讨如下几个问题： 架构模式和架构风格有区别吗？ 什么是架构模式？ 什么是架构风格？ 架构模式和架构风格的区别是什么？ 有哪些架构模式？ 有哪些架构风格？ 架构模式=架构风格？ 如果你搜索「架构模式和架构风格的区别」，你会发现答案千差万别： 有的观点认为架构模式和架构风格是一个东西，只是叫法不同 有的观点认为架构风格是架构模式的外在表现 有的观点认为架构模式和架构风格是不同的两个概念（具体有什么不同，又有不同的观点） 有的观点认为架构模式解决问题，架构风格不解决问题(例如：建房子有建房子的模式，而无论是建成哥特风还是现代风，都还是房子) 有的观点认为架构风格是高层级的架构模式 我个人的观点是： 架构模式是特定问题域下，架构风格的具体应用 ！ 我们来一个个的说！ 什么是架构模式？ 在说架构模式之前，我们先来看看我们常挂在嘴边的设计模式是怎么定义的！ GOF在《Design Patterns》这本书的「What is a Design Pattern?」小节，对设计模式下了一个明确的定义： The design patterns in this book are descriptions of communicating objects and classes that are customized to solve a general design problem in a

业务领域建模的概念 业务对象模型(也叫领域模型 domain model)是描述业务用例实现的对象模型。它是对业务角色和业务实体之间应该如何联系和协作以执行业务的一种抽象。业务对象模型从业务角色内部的观点定义了业务 用例 。该模型为产生预期效果确定了业务人员以及他们处理和使用的对象("业务类和对象")之间应该具有的静态和动态关系。它注重业务中承担的角色及其当前职责。这些模型类的对象组合在一起可以执行所有的业务用例。 业务领域建模的原因 业务建模在ERP工程中被着重强调，而且ERP中的BPR已经成为一门独立的学科。不仅如此，即便是在普通的信息系统中，业务建模也是非常重要的，所不同的，仅仅是它们的规模而已。这一点上，可能大家会不理解，如果你只是为企业的业务自动化建立应用，直接照搬企业模式不就行了吗。这里有两点原因，一是企业原有的 业务模式 在以人为主的环境中可能运行的很好，可是把这套模式原本不动的搬到计算机上就未必会适合了。人的能力和计算机的能力有很大的出入，所以流程必须经过调整以适应计算机;第二个原因是上面已经提到过的避免产生部门级的，部分功能区域的应用系统。 在 RUP 中，业务建模被作为下游流程的输入重点强调:业务模型是需求 工作流 程的一种重要输入，用来了解对系统的需求。(RUP) 业务领域建模的步骤 领域模型设计是需求分析的 关键步骤 。它帮助用户及需求分析人员建立业务概念

业务领域建模的概念 业务对象模型(也叫领域模型 domain model)是描述业务用例实现的对象模型。它是对业务角色和业务实体之间应该如何联系和协作以执行业务的一种抽象。业务对象模型从业务角色内部的观点定义了业务 用例 。该模型为产生预期效果确定了业务人员以及他们处理和使用的对象("业务类和对象")之间应该具有的静态和动态关系。它注重业务中承担的角色及其当前职责。这些模型类的对象组合在一起可以执行所有的业务用例。 业务领域建模的原因 业务建模在ERP工程中被着重强调，而且ERP中的BPR已经成为一门独立的学科。不仅如此，即便是在普通的信息系统中，业务建模也是非常重要的，所不同的，仅仅是它们的规模而已。这一点上，可能大家会不理解，如果你只是为企业的业务自动化建立应用，直接照搬企业模式不就行了吗。这里有两点原因，一是企业原有的 业务模式 在以人为主的环境中可能运行的很好，可是把这套模式原本不动的搬到计算机上就未必会适合了。人的能力和计算机的能力有很大的出入，所以流程必须经过调整以适应计算机;第二个原因是上面已经提到过的避免产生部门级的，部分功能区域的应用系统。 在 RUP 中，业务建模被作为下游流程的输入重点强调:业务模型是需求 工作流 程的一种重要输入，用来了解对系统的需求。(RUP) 业务领域建模的步骤 领域模型设计是需求分析的 关键步骤 。它帮助用户及需求分析人员建立业务概念