–ignore=<file> 不进行检查的文件列表 –disable=<msg ids> 关闭某种类型的检查 –f <format> 报告类型，如htmlpylint –help-msg <msg-id> #查看某种类型问题的帮助pylint –generate-rcfile #根据当前配置生成配置文件
每一个“人造物”都是一个内部环境与外部环境的“接口”。对这个接口的描述就是需求。
7.3需求的类型
需求分类：（1）产品/过程：产品需求吗，过程需求；（2）产品需求：功能性需求，非功能性需求；（3）抽象层次详细程度：业务需求，用户需求，系统需求，软件设计规约。
业务需求：业务目标，指可以帮助企业达成组织目标的需求项。
系统需求：使得系统实现预期的功能，它从用户的角度描述系统在做什么，与系统是由什么硬件和软件实现无关。
软件需求：是指关于系统中软件部分的需求，它的满足帮助实现系统需求。
用户需求：是指其满足会影响系统的用户接受程度的需求，有时候，被称为“用户接口需求”。
功能性需求：是指满足系统需求需要提供的功能，有时候，也被称为“行为需求”。
非功能性需求：定义软件系统以及软件开发过程为满足系统功能需求要满足的其他约束条件。
质量需求：描述软件系统正常工作时需要满足的额外的、与质量相关的要求，也称之为“质量属性”。
依从性需求：着重描述软件对国家法律、国际公约、社交法则、文化与政治习惯、标准等环境约束的满足要求。
体系结构设计需求：系统环境对待设计系统在结构上的约束。分布式约束：要求软件系统组件满足目标组织由于地理自然分布导致的对系统设备各节点的分布要求，以及数据的分布式存储于处理要求。安装约束：要求软件系统能够在目标实现环境下正常运行。
设计开发约束：是对软件系统设计过程的约束。包括：开发成本、开发周期、产品特征的变化性、可维护性、可重用性、可移植性等。
7.4需求的主要来源
需求过程活动：需求抽取（Elicitatiobn），需求分析（Analysis），需求规约（Specification），需求管理（Management），需求验证（Validation）。
需求抽取技术：协同工作，面谈，问卷调查，观察法，原型法，文档分析，建模，角色扮演，非功能性需求列表。冲突识别与磋商。
需求分析：对产品及其与环境的交互进行更深入的了解，识别系统需求，设计软件体系结构，建立需求与体系结构组件间的关系，在体系结构设计实现过程中进一步识别矛盾冲突，并通过干系人之间的协调磋商解决问题。
需求验证：对其他需求工程活动的质量的保证。通过数学的形式化工具或工程化的测试过程来确保系统满足干系人的要求。验证方法：评审、原型化、模型验证、确认测试。
需求管理：涉及软件配置管理、需求跟踪、影响分析和版本控制。需求跟踪、变更请求管理、需求属性管理。
7.5需求工程过程
四世界模型：主题世界+系统世界+开发世界+应用世界。
出发点：确定干系人》定义边界》定义目标与情景实例》分析可行性》分析风险。
干系人的参与至关重要。
分析现有系统有助于了解未来系统的工作数据。
7.6需求获取技术
包括：面谈、问卷调查、群体诱导技术、参与调查法、文档分析、头脑风暴、情景分析、原型化方法、建模方法、需求讨论会。
竞争性需求分析：需求、方法、收益、竞争、推广。
A/B测试：确定待试验的两种UI，确定衡量标准，确定数据搜集流程，确定试验运行时间，确定人数，A/B测试的技术实现，搜集数据，分析数据，做出结论。
用户行为数据在线采集：用户操作数据采集（交互过程数据、眼动数据、页面访问时间、访问内容数据、用户偏好数据等），操作数据统计（产商、版本、IP地址、日访问量、地域信息、访问频次、用户身份、访问时长、打分等）。
获取技术选择：界面（原型、情景与建模），业务逻辑（参与观察、亲身实践、面谈和情景），信息（面谈，现有系统分析）。
7.7撰写需求文档
组织形式：
（1）文档需要有逻辑组织结构：参照IEEE的模板
（2）典型的组织形式包括：按系统能够响应的各种外部环境情况来组织；按系统特征来组织；按系统的响应方式来组织；按所管理的外部数据对象来组织；按用户类型来组织；按软件的工作模式来组织；按子系统的划分来组织。
软件需求规格说明SRS的风格：描述性的自然语言文本（用户故事）；从用例模型产生（用例模型与需求转化可看成可逆的过程；如果需求模型以用例的形式表示，我们可以逆向生成需求的完整集合）；从需求数据库中生成（商业需求数据库有内置的功能来生成经过筛选的需求规格说明；从产品线需求规格数据库中生成特定产品的需求规格说明）；从混合模型中生成（特征模型和用例模型）。
用户手册大纲：介绍（产品总览及基本原理；术语和基本特征；展示格式与报表格式的总结；手册的大纲）；开始（开始指令；帮助模式；样例运行）；操作模式（命令行/对话框/报告）；高级特性；命令语法和系统选项。
IEEE-830 SRS模板大纲（介绍，术语表，用户需求规格说明，系统结构，系统需求规格说明，系统模型，系统的演化，附录，索引）。
IEEE-830 SRS模板第三部分：
8.4建模工具介绍
系统建模工具的主要功能：
可视化表达：UML模型；Web模型，例如Azure；数据库模型，例如Power Designer；用户自定义模型，例如Visio。
画图工具：StarUML，Visio
常用系统建模工具（UML2.0）：IBM Rational Rose ；JUDE；Enterprise Architect（EA）。
8.5微信抢票应用案例
（1）参与者列表：活动参与者，活动组织者，后台管理员，微信平台，系统时针。
（2）用例列表：发布活动，管理活动，绑定用户，退票，抢票，选择座位，浏览活动信息，推送活动。
9.面向对象分析与设计
9.1面向对象分析
面向对象分析（Object-Oriented Analysis,OOA）：
面向对象分析技术关注应用领域中的实体，并将其建模为对象；
面向对象分析技术主要基于分裂、泛化、聚合关系在对象集合之间建立结构；
对象的行为时执行预定的动作（服务/活动）；
对象通过执行动作来完成状态变迁。
面向对象分析的起源：
面向对象程序设计（OOP）：将OOP中的概念上推到分析和设计阶段；
数据库设计：将数据语义建模概念，如实体-关系、泛化、聚合和分类用于系统分析和设计；
结构化设计：将结构化分析方法与技术，如SADT方法等用于系统分析与建模；
知识表示：采用基于问题框架和语义网络的知识表示方法。
举例：
Peter coad的面向对象方法【coad91】
“对象”是问题领域中真实存在的实体，有“定义清晰的边界”；对象中封装有属性和行为；面向对象分析的五个核心概念：对象、属性、结构、服务和主题。
继承/一般-特殊结构（Gen-Spec Structures）
一般-特殊结构将类组织成基于继承关系的分类层次结构；自底向上是从特殊到一般的类（generalization）；自顶向下是从一般到特殊的类（specialization）。
整体-部分结构（Whole-Part Structures）
整体-部分结构描述对象间的组合关系。例如，一个交通灯对象由0-3个灯组，支撑杆和位置对象组合而成。
服务建模（Services）
对象为其周遭的其他对象提供服务，例如，医生对象对外提供的服务包括：体检、出体检报告。
三种服务的类型：瞬时服务Occurrence services（对象的创建、结束、修改等）；计算服务Calculate services（对象为其他对象完成计算任务等）；监控服务Monitor services（对象持续监控流程，检查预设条件是否满足）。
用带箭头的虚线来表示一个对象引用另一个对象的服务。==服务关系（services relationships）
面向对象的分析方法学
识别对象和类（类是对象的抽象定义）；
识别类之间的关系，建立由继承和组合关系组成的类层次结构；
定义主题，通过主题将对象模型组织成多个抽象层次或视角，一般说来通过继承关系或整体部分关系联系起来的类同属于一个主题；
识别各个对象内部的属性信息，并将其赋予相应抽象层次的类；
为每个类定义服务。
9.2CRC卡片分拣法
识别类的方法
根据用例描述中的名词确定类的候选者；
使用CRC分析法寻找类：CRC是类（class）、责任（responsibility）和协作（collaboration）的简称，CRC分析法根据类所要扮演的职责来确定类；
根据边界类、控制类和实体类的划分来帮助发现系统中的类；
参考分析、设计模式来确定类。
对象几乎无处不在
外部实体（与建模中系统存在交互）；事物（建模的应用领域中存在的事物）；事件（系统上下文中发生）；角色（由与系统交互的人扮演的角色）；组织单元（与应用领域相关的部分）；位置、地点（建模中的问题的物理上下文）；结构体（定义类或者对象组合）。
不能定义为类的事物：过程（打印、转换）；属性（兰颜色，50Mb）。
类筛选
排除以下的类：超出问题关注范围的类；指代整个系统的类；功能重复的类；过于含糊或过于具体的类；可观察到的现象是，实例对象过多过少。
筛选原则：保存对象信息；提供所需服务；具有多个属性；具有公共属性；具有公共操作；外部实体。
类识别
从原始资料中识别类：找出干系人提交的问题描述中名词即短语；如果他描述应用领域中的信息结构或本质，则加入模型。
从其他来源识别类：背景信息调查，用户及干系人提供，分析模式；
最好识别出尽可能多的候选类：之后逐步按照其价值功用进行选择；明确判断后排除一个类要比压根不考虑来的合理。
识别职责类的功能职责
功能职责关乎行为动作，因此是问题描述中的动词…
识别类交互协作关系：用UML用例图
识别对象及其消息交互
注意：目的并非写出所有场景，而是对类和职责定义进行精化…
9.3面向对象设计
面向对象设计过程
进行适当的领域分析；
撰写问题描述，确定系统的开发任务；
基于问题描述抽取需求；
开发用户界面原型；
识别对象类；
定义每个类的职责；
确定类之间的交互关系；
建立系统的设计模型。
面向对象思维方式的核心理念
区分接口与实现【接口的标准化vs实现的演化】；
用户代码==》接口==》oracle、db2、SQLany
从具体到抽象；
抽象的接口：向用户暴露尽可能少的实现细节；
让用户知道的过于类的内部实现细节越少越好；
最小用户负担原则；
确定用户：面向服务的原则（services principle）
确定对象行为：用例！！以往的设计决策在我们定义抽象接口时候会发生变化；
识别环境约束：环境对对象的行为施加约束限制条件：前置条件/后置条件/例外条件…
确定实现细节：公共接口以外的内容都可以看做是实现相关的。
最小接口原则
开闭原则（Open/Closed Principle,OCP）：
最初由Bertrand Meyer提出；
软件实体在扩展性方面应该是开放的，而在更改性方面应该是封闭的。
依赖倒置原则（Dependency Inversion Principle，DIP）：
依赖倒置原则指的是依赖关系应该是尽量依赖接口（或抽象类），而不是依赖于具体类。
接口分离原则（Interface Segregation Principle，ISP）：
在设计时采用多个和特定客户类（client）有关的接口要比采用一个通用的接口要好。分为：使用通用接口设计和使用分离接口设计。
好的系统设计的特征
用户友好，易理解， 可靠，可扩展，可移植，可伸缩，可重用，…，简单性：实现简单，使用简单，理解简单，维护简单；
9.4类图建模
什么是类/strong>
类是具有以下特征的对象集合：相同性质（attributes），相同行为（operations），相同的对象关系，相同的语义（“semantics”）。
对象
对象是类的实例，表示为：两个不同的对象可以有相同的属性取值（正如两个同名的人，或者住在同一栋楼的人）；
对象与其他对象之间发生关联关系；
注意将属性划归正确的类。
类属性定义
属性在类图标的属性分隔框中用文字串说明，UML规定属性的语法为：【可见性】属性名【：类型】【【多样性【次序】】】【=初始值】【{约束}】
类关系
对象并非遗世独立，对象间存在千丝万缕的联系
UML中，关注以下几种类型的关系：
关联关系（association）
来源：hehuanlin123
声明：本站部分文章及图片转载于互联网，内容版权归原作者所有，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！