课程名称 软件建模与分析 班级 18软工5班
专题名称 个人的需求分析与建模读书心得与对你组项目的发展建议 教导教师 董瑞生
姓名 李子泓 学号 1814080902521 日期 2020年12月19号
A Functional Requirement (FR) is a description of the service that the software must offer. It describes a software system or its component. A function is nothing but inputs to the software system, its behavior, and outputs. It can be a calculation, data manipulation, business process, user interaction, or any other specific functionality which defines what function a system is likely to perform. Functional Requirements are also called Functional Specification.
功能需求(FR)是软件必须提供的服务的描述。它描述了一个软件系统或其组件。函数不过是对软件系统、其行为和输出的输入。它可以是计算、数据操作、业务流程、用户交互,或者其他定义系统可能执行的功能的特定功能。功能性需求也被称为规格化。
Details of operations conducted in every screen 在每个屏幕上执行操作的详细情况
Data handling logic should be entered into the system 数据处理逻辑应该输入到系统中
It should have descriptions of system reports or other outputs 它应该有系统报告或其他输出的说明
Complete information about the workflows performed by the system 关于系统执行的工作流的完整信息
It should clearly define who will be allowed to create/modify/delete the data in the system 它应该清楚地定义谁将被允许在系统中创建/修改/删除数据
How the system will fulfill applicable regulatory and compliance needs should be captured in the functional document 系统将如何满足适用的法规和法规遵从性需求应该在功能文件中得到体现
Helps you to check whether the application is providing all the functionalities that were mentioned in the functional requirement of that application 帮助您检查应用程序是否提供了该应用程序的功能需求中提到的所有功能
A functional requirement document helps you to define the functionality of a system or one of its subsystems. 功能需求文档可以帮助您定义系统或其子系统之一的功能
Functional requirements along with requirement analysis help identify missing requirements. They help clearly define the expected system service and behavior. 功能需求和需求分析有助于识别缺失的需求,它们有助于清楚地定义预期的系统服务和行为
Errors caught in the Functional requirement gathering stage are the cheapest to fix. 在函数式需求收集阶段捕获的错误是最便宜的修复方法
Support user goals, tasks, or activities 支持用户目标、任务或活动
Here, are the most common functional requirement types
以下是最常见的功能需求类型
Transaction Handling 交易处理
Business Rules 业务规则
Certification Requirements 认证规定
Reporting Requirements 申报规定
Administrative functions 行政职能
Authorization levels 授权级别
Audit Tracking 审计跟踪
External Interfaces 外部接口
Historical Data management 历史数据管理
Legal and Regulatory Requirements 法律及规管要求
Putting in unjustified extra information that may confuse developers 添加不合理的额外信息,可能会让开发人员感到困惑
Not putting sufficient detail in the requirement document. 在需求文档中没有提供足够的详细信息
You add rules or examples, scoping statements or objectives anything except the requirement itself. 您可以添加规则或示例、范围语句或目标,但需求本身除外
Left out a piece of important information that is an absolute must to fully, accurately, and definitively state the requirement. 遗漏了一个重要的信息,这是绝对必须完全、准确和明确地陈述需求
Some professionals start to defend the requirements they have documented when the requirement is modified, instead of finding the correct truth. 当需求被修改时,一些专业人员开始维护他们所记录的需求,而不是寻找正确的真相
Requirements which are not mapped to an objective or principle. 没有映射到目标或原则的需求
我们的软件产品或者项目,其需求都有三个维度,业务需求、用户需求和功能需求,除此之外,每个系统还有各种非功能需求。
功能性需求(Functional requirement)的含义从字面上就可以很好地理解,指的是软件本身需要实现的具体功能, 比如"正常用户使用正确的用户名和密码可以成功登录"、"非注册用户无法登录"等,这都是属于典型的显式功能性需求描述。
非功能性需求主要涉及安全性、性能以及兼 容性三大方面。 在上面所有的测试用例设计中,我们完全没有考虑对非功能性需求的测试,但这些往往是决定软件质量的关键因素。
用户需求:在决定购买之前,用户想方便的比较一下几个同系列产品,以此在选择的时候做出更明智的决定。
功能需求:我们可以让用户把购买的商品,都放入"比较栏",然后用户再点击"去对比",就会在一个界面同时对比几个产品。
用户需求是前提条件,功能需求是落下来的产品部分,它是可以交付的。
值得注意的一点是业务需求,有时候用户需求与业务需求是有矛盾 ,那么个功能需求怎么决定呢?
举个例子:
某个商品界面,我发现我的用户不是为了买最便宜的货,我决定产品不把最便宜的商品都展示出来,因为去1、不希望让用户买最便宜货;2、一旦有太便宜的商品,用户就会形成心理落差,觉得贵的商品不值钱(其实贵的商品的性价比比便宜的商品更高);3、我想提高单笔成交订单额度。
所以我就会只展示相对贵一点的商品。让用户减少选择,就有可能购买价值更贵的商品(业务需求)
如果把最便宜的商品也展示出来,这对于用户需求来说是有价值的;(用户需求)
但是还是坚持了"贵一点"的策略,这就是业务需求主导了功能需求;
对于我们小组的实验室设备管理系统来说,有许多功能性的需求,例如设备报修的功能,查看所有设备的功能等等。
Data flow diagram or data flow diagram, abbreviated as DFD. Data flow diagram (DFD) is a graphic tool to describe the data flow in a system. It marks the logical input and output of a system, as well as the processing needed to convert the logical input to the logical output.
数据流图或数据流程图(Data Flow Diagram),缩写为DFD。数据流图DFD是描述系统中数据流程的一种图形工具,它标志了一个系统的逻辑输入和逻辑输出,以及把逻辑输入转换逻辑输出所需的加工处理。
The technical definition of this technique from the International Institute of Business Analysis (IIBA®) is: “Data flow diagrams show where data comes from, which activities process the data, and if the output results are stored or utilized by another activity or external entity.” – BABOK® v3.0
These types of diagrams simply depict the sources of data, what happens to the data, and where it goes to be used.
Source – where the data comes from
Activities – what happens to the data
Inputs/Outputs – what goes in, and what comes out
Transformations – any changes that take place to the data
Temporary or permanent repository locations – where the data lives
数据来源
活动------数据发生了什么变化
输入/输出-什么进去,什么出来
转换------对数据发生的任何更改
临时或永久存储库位置------数据所在的位置
Logical information flow of the system 系统的逻辑信息流
Determination of physical system construction requirements 物理系统结构要求的确定
Simplicity of notation 简单的符号
Establishment of manual and automated systems requirements 建立手动和自动系统要求
系统的逻辑信息流
物理系统结构要求的确定
简单的符号
建立手动和自动系统要求
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-dD6y3IEE-1609755291765)(media/image1.png)]{width=“3.0388888888888888in” height=“4.233333333333333in”}
数据流图也称为气泡图。DFD是系统设计自上而下方法中使用的一种设计工具。这个上下文级别的DFD接下来是"爆炸式"的,以产生一个1级的DFD,显示正在建模的系统的一些细节。Level 1 DFD显示了系统如何分成子系统(过程),每个系统处理一个或多个来自或来自外部代理的数据流,它们一起提供系统的所有功能整个。它还识别必须存在的内部数据存储库,以便系统执行其工作,并显示系统各个部分之间的数据流。
数据流图是结构化系统分析和设计方法SSADM的三个基本视角之一。项目发起人和最终用户需要在系统演进的各个阶段得到简要介绍和咨询。通过数据流图,用户可以看到系统将如何运行,系统将完成什么以及如何实现系统。可以绘制旧系统的数据流图,并与新系统的数据流图进行比较,以便比较以实现更高效的系统。数据流图可以用来为最终用户提供一个物理的概念,即它们输入的数据最终对整个系统的结构从订单到发送到报告有影响。如何开发系统可以通过数据流图模型来确定。
在开发一组的过程中整平数据流图分析员/设计者被迫处理系统可以如何被分解为分量的子系统,以及标识的交易数据中的数据模型。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-9QYQeyc1-1609755291766)(media/image2.png)]{width=“5.7659722222222225in” height=“3.6930555555555555in”}
根据层级数据流图分为顶层数据流图、中层数据流图和底层数据流图。除顶层数据流图外,其他数据流图从零开始编号。
顶层数据流图只含有一个加工表示整个系统;输出数据流和输入数据流为系统的输入数据和输出数据,表明系统的范围,以及与外部环境的数据交换关系。
中层数据流图是对父层数据流图中某个加工进行细化,而它的某个加工也可以再次细化,形成子图;中间层次的多少,一般视系统的复杂程度而定。
底层数据流图是指其加工不能再分解的数据流图,其加工称为"原子加工"。
在单张数据流图时,必须注意以下原则:
一个加工的输出数据流不应与输入数据流同名,即使它们的组成成分相同。
保持数据守恒。也就是说,一个加工所有输出数据流中的数据必须能从该加工的输入数据流中直接获得,或者说是通过该加工能产生的数据。
每个加工必须既有输入数据流,又有输出数据流。
所有的数据流必须以一个外部实体开始,并以一个外部实体结束。
外部实体之间不应该存在数据流
对于dataflow dirgram(数据流图),我的理解是通过数据流图,软件设计师可以自顶而下的分析系统的信息流程、在图上确定需要计算机处理的部分、向数据库设计过渡、根据数据流向确定存取方式、能够确定一个处理过程。而在测试过程中,数据流图可以方便、直接的帮助程序员查找到错误的发生位置。
需求分析阶段,为了获得一个对新系统的框架认识、概念性认识,需要对新系统建模。而用图形表示需求,就是需求建模,获得分析模型。需求分析方法中的结构化分析方法的特点是利用数据流图来帮助人们理解问题,对问题进行分析。
画数据流图时一要确定系统的输入输出,由于系统究竟包括哪些功能可能一时难于弄清楚,可使范围尽量大一些,把可能有的内容全部都包括进去。此时,应该向用户了解"系统从外界接受什么数据"、"系统向外界送出什么数据"等信息,然后,根据用户的答复画出数据流图的外围。
二要由外向里画系统的顶层数据流图,首先,将系统的输人数据和输出数据用一连串的加工连接起来。在数据流的值发生变化的地方就是一个加工。接着,给各个加工命名。然后,给加工之间的数据命名。最后,给文件命名。
三要自顶向下逐层分解,绘出分层数据流图
对于大型的系统,为了控制复杂性,便于理解,需要采用自顶向下逐层分解的方法进行,即用分层的方法将一个数据流图分解成几个数据流图来分别表示。
例如我们小组的实验室设备管理系统项目,其中涉及到许多数据的流动,就可以通过画数据流图的办法进行分析,像实验室设备的管理,对于实验室一个设备的信息,在报修时需要进行传输数据,去向管理员子系统的报修管理表中等等。
Acceptance testing, a testing technique performed to determine whether or not the software system has met the requirement specifications. The main purpose of this test is to evaluate the system’s compliance with the business requirements and verify if it is has met the required criteria for delivery to end users.
验收测试,一种测试技术,用于确定软件系统是否满足需求规范。这项测试的主要目的是评估系统是否符合业务要求,并核实系统是否符合向最终用户交付的必要标准。
User acceptance Testing用户验收测试
Business acceptance Testing业务验收测试
Alpha Testing测试
Beta Testing测试版
Acceptance criteria are defined on the basis of the following attributes
验收标准是根据以下属性定义的:
Functional Correctness and Completeness函数的正确性和完整性
Data Integrity数据完整性
Data Conversion数据转换
Usability可用性
Performance工作表现
Timeliness及时性
Confidentiality and Availability机密性和可用性
Installability and Upgradability可安装性和可升级性
Scalability可扩展性
Documentation文件
“ATDD”,全称"Acceptance Test Driven Development “,中文称"验收测试驱动开发”。ATDD和TDD的区别是什么呢,查了一些资料,我的理解如下:
先介绍一下TDD,引用Wikipedia上的关于TDD的介绍:
Test-driven development (TDD) is a [software development process]{.ul} that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated [test case]{.ul} that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally [refactors]{.ul} the new code to acceptable standards.
TDD只涉及到Developer(开发者),只能算个人工作方式的改变。而现代软件开发,往往都是"产品经理(或业务)、测试人员(或QA)、开发人员"三者合作的成果,如果开发人员对业务需求理解的不正确,那么写出的测试用例也是错的,这个问题是TDD解决不了的。中文Wikipedia上对于TDD缺点的描述,也把这一问题列在第一位:
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-d0r1XkYb-1609755291770)(media/image4.png)]{width=“5.995138888888889in” height=“2.1041666666666665in”}
ATDD又如何解决这个问题呢?《Explore It!: Reduce Risk and Increase Confidence with Exploratory Testing》这本书的作者Elisabeth Hendrickson给出了下面的解释:
Acceptance Test Driven Development (ATDD) is a practice in which the whole team collaboratively discusses acceptance criteria, with examples, and then distills them into a set of concrete acceptance tests before development begins. It’s the best way I know to ensure that we all have the same shared understanding of what it is we’re actually building. It’s also the best way I know to ensure we have a shared definition of Done.
整个团队(包括上面提到的三方成员)在开发工作开始之前,一起讨论、制定每个任务(或者用户故事)的验收标准,并提取出一组验收测试用例。这么做好处在于:
大家一起讨论验收标准和测试用例保证了对业务需求一致的理解。(这一点实际是所有开发环节中都需要关注的问题)
通过形成测试用例,使标准成为可执行的内容,而不是虚的指标。
国内公司一般项目开发进度很紧,大部分公司开发和测试工作由不同的人来负责,完全照搬TDD流程来开发成本过高。我更建议开发人员使用自动化测试技术编写验收测试用例,只要验收测试用例能够跑通了,就可以提交测试。
验收测试(Acceptance Test):在软件产品完成了功能测试和系统测试之后、产品发布之前所进行的软件测试活动。它是技术测试的最后一个阶段,也称为交付测试。
验收测试的目的:确保软件准备就绪,并且可以让最终用户将其用于执行软件的既定功能和任务。
验收测试的参与者:用户,还可能有软测工程师等。
The phrase change review board (also known by the acronym CCB) refers to any group of individuals within a project team or project group who are responsible for making the ultimate decision as to when and if any particular changes are to be made in regards to work products or schedule events.
短语变更审查委员会(也称为简称 CCB)指的是项目团队或项目组中的任何个人小组,他们负责就何时以及是否对工作产品或安排事件作出任何特定变更作出最终决定。
The process in which the Change Control Board determines when and if a series of changes should be made is two fold. First, the Change Control Board needs to review and study the impact of the proposed changes on the items in question, and then, after making that evaluation, the Change Control Board can then either approve the changes, reject the changes, or, in some cases, request more information or postpone the decision pending some other occurrences to take place that would factor into their ultimate choice. Significant changes that will in fact affect baselines are almost always put through the CCB for approval.
变更控制委员会决定何时以及是否应该进行一系列变更的过程有两个方面。首先,变更控制委员会需要审查和研究拟议的变更对有关项目的影响,然后,在进行评估之后,变更控制委员会可以批准变更、拒绝变更,或者在某些情况下要求提供更多信息或推迟作出决定,直到发生一些将成为其最终选择因素的其他事件。实际上会影响基线的重大更改几乎总是通过建设银行提交审批。
这个术语在 PMBOK 的第三版和第四版中定义。
通过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录软件产品的演化过程,确保软件开发者在软件生命周期中各个阶段都能得到精确的产品配置。
配置管理过程是对处于不断演化、完善过程中的软件产品的管理过程。一致性、可追溯性,使产品极大程度地与用户需求相吻合。它通过控制、记录、追踪对软件的修改和每个修改生成的软件组成部件来实现对软件产品的管理功能。
软件配置管理的最终目标是管理软件产品。由于软件产品是在用户不断变化的需求驱动下不断变化,为了保证对产品有效地进行控制和追踪,配置管理过程不能仅仅对静态的、成形的产品进行管理,而必须对动态的、成长的产品进行管理。由此可见,配置管理同软件开发过程紧密相关。配置管理必须紧扣软件开发过程的各个环节:管理用户所提出的需求,监控其实施,确保用户需求最终落实到产品的各个版本中去,并在产品发行和用户支持等方面提供帮助,响应用户新的需求,推动新的开发周期。通过配置管理过程的控制,用户对软件产品的需求如同普通产品的订单一样,遵循一个严格的流程,经过一条受控的生产流水线,最后形成产品,发售给相应用户。从另一个角度看,在产品开发的不同阶段通常有不同的任务,由不同的角色担当,各个角色职责明确,泾渭分明,但同时又前后衔接,相互协调。
好的配置管理过程有助于规范各个角色的行为,同时又为角色之间的任务传递提供无缝的接合,使整个开发团队像是一个交响乐队一样和谐而又错杂地行进。正因为配置管理过程直接连接产品开发过程、开发人员和最终产品,这些都是项目主管人员所关注的重点,因此配置管理系统在软件项目管理中也起着重要作用。配置管理过程演化出的控制、报告功能可帮助项目经理更好地了解项目的进度、开发人员的负荷、工作效率和产品质量状况、交付日期等信息。同时配置管理过程所规范的工作流程和明确的分工有利于管理者应付开发人员流动的困境,使新的成员可以快速实现任务交接,尽量减少因人员流动而造成的损失。
实施配置管理系统,一般的步骤和需要考虑的问题如下:
规划、调整网络开发环境
一个规划良好的开发环境,是实施配置管理系统的前提。在此阶段,要对配置管理系统做出规划,主要考虑以下问题:
网络的带宽、拓扑结构
服务器的选择、命名规范
存储区的定位
开发人员及组的命名规约等
设计配置管理库
根据项目开发的要求,设计开发资源的存储模式,良好的存储模式有利于减轻管理上的负担,增强配置管理库的访问性能,同时便于控制访问权限,保护软件资产。
定义配置管理系统的角色
在此阶段,需要确定与配置管理相关的所有角色,包括他所有角色相应的活动。在开发过程中,一个开发人员可能兼任多种角色,但一项任务在同一时刻只能由一个角色来执行。
一般配置管理中的角色主要包括:
项目经理:项目经理在配置管理方面的职责是依靠配置管理员、系统管理员和系统体系结构设计人员的帮助,制定项目的组织结构和配置管理策略。这些工作包括:定制开发子系统,定制访问控制,制定常用策略,制定集成里程碑,以及进行系统集成。
配置管理员:配置管理员的职责是根据项目经理制定的开发组织结构和策略,实施、维护配置管理的环境。其主要职责如下:创建配置管理库,对存储库进行日常备份和恢复,维护配置管理环境,及管理配置管理相关的用户。
软件开发人员:软件开发人员依据项目的开发和配置管理策略,创建、修改和测试开发工件。
集成人员:对软件进行归并,形成相应的基线或发布版本。
QA人员:需要对软件配置管理有较深的认识,其主要工作是跟踪当前项目的状态,测试,报告错误,并验证其修复结果。
制定配置管理流程
这是配置管理实施的一个重要阶段,其主要目的是根据项目开发的需要,制定相应的配置管理流程,以更好地支持开发,主要活动包括:
定制并行开发策略:合理的并行开发策略应该具有以下特点:协调项目的复杂性和需求,统一创建分支类型和元数据,为开发过程中的变更集成制定有效的规范,适时反映开发过程中方法和需求的变化。
发布版本管理:软件开发过程中的一个关键活动是提取工件的相关版本,以形成软件系统的阶段版本或发布版本,我们一般将其称为稳定基线。一个稳定基线代表新开发活动的开始,而一系列定制良好的活动之后又会产生一个新的稳定基线。有效地利用此项功能,在项目开发过程中可以自始至终管理、跟踪工件版本间的关联。
一般来讲,实施配置管理系统,相关人员需要接受以下培训:
管理员培训:针对配置管理员,主要学习配置管理工具管理相关内容。
开发人员培训:针对开发人员,主要学习配置管理工具与开发相关的常用操作。
管理流程培训:针对全体人员,目的是了解配置管理策略和流程,以及如何与开发管理、项目管理相结合。
CMDB --(Configuration Management Database,配置管理数据库), CMDB存储与管理企业IT架构中设备的各种配置信息,它与所有服务支持和服务交付流程都紧密相联,支持这些流程的运转、发挥配置信息的价值,同时依赖于相关流程保证数据的准确性。注意:Saltstack和puppet是配置管理,不是配置管理数据库,注重配置过程。
在实际的项目中,CMDB常常被认为是构建其它ITIL流程的基础而优先考虑,ITIL项目的成败与是否成功建立CMDB有非常大的关系。
70%~80%的IT相关问题与环境的变更有着直接的关系。实施变更管理的难点和重点并不是工具,而是流程。即通过一个自动化的、可重复的流程管理变更,使得当变更发生的时候,有一个标准化的流程去执行,能够预测到这个变更对整个系统管理产生的影响,并对这些影响进行评估和控制。而变更管理流程自动化的实现关键就是CMDB。
A requirement describing a performance characteristic (timing, speed, volume, capacity, throughput…).Is regarded in this glossary as a sub-category of quality requirements,
but can also be considered as a non-functional requirements category
描述性能特征(时间、速度、体积、容量、吞吐量…)的要求在本术语表中被视为质量要求的子类别,但也可以视为非功能需求类别
In identifying and quantifying performance requirements, it is important to identify the reasoning behind a particular requirement. This is part of the general capacity planning process. Users might be basing their statements of requirements on assumptions about the logic of the program that do not match the programmer’s assumptions.
在识别和量化性能需求时,确定特定需求背后的推理是很重要的。这是总体容量规划过程的一部分。用户的需求陈述可能是基于程序逻辑的假设,而这些假设与程序员的假设不符。
At a minimum, a set of performance requirements should document the following:
The maximum satisfactory response time to be experienced most of the time for each distinct type of user-computer interaction, along with a definition of most of the time. Response time is measured from the time that the user performs the action that says “Go” until the user receives enough feedback from the computer to continue the task. It is the user’s subjective wait time. It is not from entry to a subroutine until the first write statement.
If the user denies interest in response time and indicates that only the result is of interest, you can ask whether “ten times your current estimate of stand-alone execution time” would be acceptable. If the answer is “yes,” you can proceed to discuss throughput. Otherwise, you can continue the discussion of response time with the user’s full attention.
一套性能要求至少应记录以下内容:
对于每种不同类型的用户-计算机交互,在大多数时间内所经历的最大令人满意的响应时间,以及大多数时间的定义。响应时间是从用户执行"执行"操作的时间开始计算的,直到用户从计算机收到足够的反馈以继续执行任务。它是用户的主观等待时间。在第一个write语句之前,它不是从入口到子例程的。
如果用户否认对响应时间感兴趣,并指出只有结果感兴趣,那么您可以询问"十倍于当前估计的独立执行时间"是否可以接受。如果答案是"是",您可以继续讨论吞吐量。否则,你可以在用户的充分关注下继续讨论。
The response time that is minimally acceptable the rest of the time. A longer response time can cause users to think the system is down. You also need to specify rest of the time; for example, the peak minute of a day, 1 percent of interactions. Response time degradations can be more costly or painful at a particular time of the day.
The typical throughput required and the times it will be taking place. This is not a casual consideration. For example, the requirement for one program might be that it runs twice a day: at 10:00 a.m. and 3:15 p.m. If this is a CPU-limited program that runs for 15 minutes and is planned to run on a multiuser system, some negotiation is in order.
The size and timing of maximum-throughput periods.
The mix of requests expected and how the mix varies with time.
The number of users per machine and total number of users, if this is a multiuser application. This description should include the times these users log on and off, as well as their assumed rates of keystrokes, completed requests, and think times. You may want to investigate whether think times vary systematically with the preceding and following request.
Any assumptions that the user is making about the machines the workload will run on. If the user has a specific existing machine in mind, make sure you know that early on. Similarly, if the user is assuming a particular type, size, cost, location, interconnection, or any other variable that will constrain your ability to satisfy the preceding requirements, that assumption also becomes part of the requirements. Satisfaction will probably not be assessed on the system where the program is developed, tested, or first installed.
其余时间内可接受的最小响应时间。较长的响应时间会导致用户认为系统已关闭。您还需要指定其余时间;例如,一天中的高峰分钟,交互的1%。在一天中的某个特定时间,响应时间的降低可能更昂贵或更痛苦。
所需的典型吞吐量及其发生的时间。这不是一个偶然的考虑。例如,对一个程序的要求可能是一天运行两次:上午10:00和下午3:15。如果这是一个CPU有限的程序,运行时间为15分钟,计划在多用户系统上运行,则需要进行一些协商。
最大吞吐量周期的大小和时间。
预期的请求组合以及组合如何随时间变化。
每台机器的用户数和用户总数(如果这是多用户应用程序)。这个描述应该包括这些用户登录和注销的时间,以及他们假定的击键率、完成的请求和思考时间。您可能需要调查思考时间是否随前一个请求和后一个请求而有系统地变化。
用户对运行工作负载的机器所做的任何假设。如果用户想要一台特定的现有机器,请确保尽早知道这一点。类似地,如果用户假设某个特定的类型、尺寸、成本、位置、互连或任何其他变量将限制您满足上述要求的能力,则该假设也将成为需求的一部分。在开发、测试或首次安装程序的系统上,可能不会评估满意度。
客户方提出
客户方能提出明确的性能需求,说明对方很重视性能测试,这样的企业一般是金融、电信、银行、医疗器械等;他们一般对系统的性能要求非常高,对性能也非常了解。提出需求也比较明确。
曾经有一个银行项目,已经到最后的性能测试极端,因为数据库设计不合理,导致性能出现很大的问题,最终不得不把整合项目作废,对于这样的项目,其实从分析设计阶段就应该考虑系统的性能问题。性能测试也一样,对于某些项目来说越早进行越好。当然,前期的性能测试为单元性能测试、接口性能测试,有别系统性能测试。
根据历史数据分析
对于一些面向用户的独特产品,比较难定位市场的大小,可以先上一运营一段时间,通过运营可以搜集客户资料,比如,每月、每星期、每天的峰值业务量是多少。用户以什么样的速度在递增中。用户对系统的哪些功能模块使用的最多,他们所点的比例等等。收集到这些数据之后,我们就可评估系统的系统需求指标,从而进行性能测试。
需求分析与定位
这里根据前期的需求分析与定位,来分析确定系统性能指标。例如某省幼儿园管理系统。统计全省有多少家幼儿园,系统的使用时间为幼儿到校之后,管理人员对幼儿的到校情况进行录入,以及幼儿的午饭,放学情况的录入时间。经过与需求人员交流分析也能得到比较明确的性能指标。
参考历史项目或其它同行业的项目
如果公司之前有类似的项目经验,根据项目大小及上次性能测试的一些指标。从根据项目的规模可以制定出相应的性能指标。
即使本公司没有类似的项目,但其它公司有类似的项目,例如做IPTV或者DVB计费系统的测试,可以参考电信计费系统的需求------虽然不能完全照搬数据,但是可以通过其他行业成熟的需求来了解需要测试的项目有哪些,应该考虑到的情况有哪些种。
参考其它资料数据
如果你做的是非常独特的产品,市场上没有此类型的产品,而且需求及市场也难以估计,那么只能从与产品相关的资料中寻找痕迹了。不过,相信这样不确定性的产品,老板要承担的风险也是挺大的。
需要说明的是,我上面介绍的方面并非是独立的,可以综合的使用,你可以根据客户提出的指标,再根据历史数据以及参考同类型项目来进行。这样可以更确定你的性能指标是客户(或自己)真正需要的、最符合项目需求的。
对于我们所设计的系统来说,性能上的需求是必不可少的,若是没有性能上的需求,设计出来的系统可能是无法使用的,在设计实验室设备管理系统的时候,要充分考虑系统的数据类型支持,数据量支持,以及系统的并发性等等性能上的需求。
SRS is a specification for a specific software product, program or group of programs that performs a defined function in a specific environment. SRS can be written by one or more personnel from the supplier, customer or both parties, and it is recommended that the personnel of both parties jointly prepare.
SRS是对在具体环境中执行确定功能的特定软件产品、程序或一组程序的规格说明。 SRS可由来自供方、顾客或双方的一个或多个人员来编写,推荐双方人员联合编写。
软件需求规格文档包含:
硬件
功能
性能
输入输出
接口需求
警示信息
保密安全
数据与数据库
文档说明
法规说明
软件需求规格说明文档的产生阶段
对业务需求的定义和文档化,形成了前景和范围文档
对用户需求的定义和文档化,形成了用户需求文档,其中以用例说明书最常见
在得到用户需求后,需求工程师对其建模和分析,细化为系统需求,并建立满足系统需求的解决方案,对系统需求、解决方案的定义和文档化产生了系统需求规格说明文档
软件需求规格说明文档的产生阶段:对系统需求、解决方案的定义和文档化阶段
需求开发过程中的常见文档:
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ux67uKmf-1609755291772)(media/image5.png)]{width=“5.763194444444444in” height=“4.774305555555555in”}
需求规格说活动过程
第一,选择文档模板
第二,裁剪文档模板
大三,文档写作
第四,产生软件需求规格文档
需求规格说文档编写目的;
可以帮助记忆
帮助发现需求存在的问题
记录系统解决方案
为后续活动的依据
为协议基准,可以作为合同的一部分,有法律效应
需求说明文档常见读者群体:
项目管理者
设计人员和程序员
测试人员
文档写作的特点
完整性
一致性
可修改性
可跟踪性
可阅读性
可维护性
无二义性
运行和维护阶段的可使用性
文档化的主要目标是:交流
文档写作的注意事项:
明确文档编写目的
按照写作模板写作
格式规范
SRS(Software Requirements Specification)软件需求说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解, 使之成为整个开发工作的基础。包含硬件、功能、性能、输入输出、接口界面、警示信息、保密安全、数据与数据库、文档和法规的要求。
说明编写这份软件需求说明书的目的,指出预期的读者。软件需求说明书的作用在于便于用户、开发人员进行理解和交流,反映出用户问题的结构,可以作为软件开发工作的基础和依据,并作为确认测试和验收的依据。
SRS(Software Requirements Specification)软件需求说明书也是本学期软件需求分析与建模课程学习的重点,经过系统的学习,将项目开发以软件需求说明书的形式展现给各种与项目相关的角色看,有利于沟通与交流,并且作为系统最终验收的依据
A steering committee is an advisory body that’s part of IT—or other—governance. Members include experts, authority figures, and senior stakeholders in a project or organization.
程序委员会是一个咨询机构,是 it (或其他)治理的一部分。成员包括项目或组织中的专家、权威人士和高级利益相关者。
A steering committee is an advisory body that’s part of IT—or other—governance. Members include experts, authority figures, and senior stakeholders in a project or organization. As a result, they have a significant stake in how each project is managed. Thus, key concerns for steering committees are the direction, scope, budget, timeliness, and methods used. Steering committees generally meet periodically to discuss each of these aspects and help set, or reset, direction.
指导委员会是一个咨询机构,是 it (或其他)治理的一部分。成员包括项目或组织中的专家、权威人士和高级利益相关者。因此,他们在如何管理每个项目中有着重要的利害关系。因此,指导委员会关注的主要问题是方向、范围、预算、时间和使用的方法。指导委员会通常定期召开会议,讨论每个方面,并帮助设定或重置方向。
Members of the steering committee don’t usually perform the work they prescribe. Instead, senior managers or executives, important external stakeholders, and experts usually make up the committee. The particular makeup of each steering committee depends on the scope. For example, a project steering committee may involve the project manager and external stakeholders from customers. Meanwhile, an organizational steering committee may be made up of executives, certain board members, and department heads.
指导委员会的成员通常不会完成他们规定的工作。相反,委员会通常由高级经理或执行官、重要的外部利益相关者和专家组成。每个指导委员会的具体组成取决于范围。例如,项目指导委员会可能包括项目经理和来自客户的外部涉众。同时,组织指导委员会可由行政人员、某些董事会成员和部门主管组成。
While the actual makeup of each steering committee may vary slightly, there are a few guidelines to keep in mind. Arguably most important, there should be a chairperson. The chairperson should be elected by the rest of the committee and should not own the project the committee is steering. This allows for more impartial chairing. In addition, the steering committee should be made up of diverse members. Moreover, these members should equally represent the various functions the steering committee oversees. This allows for the sharing of different opinions and ideas. In parallel, the committee must allow for open discussion so that each opinion can be heard and assessed. Finally, it must have clear goals and a well-managed agenda.
虽然每个指导委员会的实际组成可能略有不同,但有一些指导方针需要牢记。可以说,最重要的是,应该有一个主席。主席应由委员会其他成员选举产生,不应拥有委员会正在指导的项目。这允许更公正的主持。此外,指导委员会应由不同的成员组成。此外,这些成员应同样代表指导委员会监督的各种职能。这样就可以分享不同的观点和想法。同时,委员会必须允许公开讨论,以便听取和评估每个意见。最后,它必须有明确的目标和管理良好的议程。
A steering committee is an advisory group that makes directional decisions on various organizational projects. Its members directly support project managers working toward strategic company directions.
指导委员会是一个咨询小组,就各种组织项目作出方向性决定。其成员直接支持项目经理朝着公司战略方向努力。
In practice steering committees also do the following:
在实践中,指导委员会也做以下工作:
Act as an advocate for initiatives and projects across the wider organization 在更广泛的组织中充当计划和项目的倡导者
Set the strategic direction of projects 制定项目的战略方向
Provide advice or direct input on budgeting, including assets (such as people), money, facilities, time, hiring, and marketing 在预算方面提供建议或直接投入,包括资产(如人员)、资金、设施、时间、招聘和市场营销
Establish project goals and scope as well as determine how success will be measured 建立项目目标和范围,并确定如何衡量成功
Assess and approve or reject project plans and changes to project plans 评估和批准或拒绝项目计划和对项目计划的更改
Select project managers and experts to support projects 选择项目经理和专家来支持项目
Prioritize and reprioritize project deliverables 对项目可交付成果进行优先排序和重新排序
Monitor project processes and plans 监控项目过程和计划
Resolve conflicts between parties 解决双方之间的冲突
Come up with ideas for strategy and problem solving 想出策略和解决问题的办法
Provide expert input on concerns and issues related to projects or the overall business 就项目或整体业务相关的关注点和问题提供专家意见
Develop policies and governance procedures 制定政策和管理程序
Identify, monitor, and eliminate project and business risks 识别、监控和消除项目和业务风险
Monitor project quality and adjust accordingly 监控项目质量并做出相应调整
Considering the range of functions steering committees provide, it might seem quite clear that they can increase business and project value. When working well, steering committees increase value by keeping projects on track, budgets in check, risks mitigated, and conflicts resolved. The fact that all of this happens apart from daily operations means the value gain is accentuated.
考虑到指导委员会提供的职能范围,似乎很明显,它们可以增加业务和项目价值。当运作良好时,指导委员会通过保持项目在正轨上、预算在可控范围内、风险得到缓解、冲突得到解决来增加价值。事实上,除了日常操作以外,所有这一切都意味着价值增值更加突出。
However, there’s a fine line between successful governance practices that increases value and bureaucratic governance practices that waste time and lead to poor decisions. Assuming a steering committee has followed the guidelines of having a chairperson, diverse members, and openness with clear goals, it’s a matter of what goes in that determines what comes out. Therefore, data is arguably the biggest contributor to value gain.
然而,在增加价值的成功治理实践和浪费时间并导致糟糕决策的官僚治理实践之间有一条细微的界限。假设一个指导委员会已经遵循了有一个主席,多样化的成员和明确目标的开放性的指导方针,那么决定结果的是什么。因此,数据可以说是价值增值的最大贡献者。
为了从指导委员会获得最大的价值,数据是有意义和可理解的是至关重要的。错误或难以理解的数据可能危及指导委员会及时作出知情决定的能力。另一方面,可用数据便于清晰的通信,并正确地表示事件的当前状态。
这就提出了一个问题: 如何确保正确的数据被送到指导委员会?
广义地说,业务智能是收集、存储和分析组织活动以生成报告、确定趋势和衡量性能的实践。商业智能的唯一功能是改进管理决策并为其提供信息。
这是天造地设的一对。实施业务情报做法使公司能够自动或定期生成可供指导委员会查看的报告和仪表板。这些报告和仪表板几乎肯定包含有意义的数据,因为它们可以用指导委员会定义为重要的指标填充。所有这些都有助于更好地了解项目和进展情况,使指导委员会能够明确沟通,及时作出正确决定。
The system context diagram (also known as a level 0 DFD) is the highest level in a data flow diagram and contains only one process, representing the entire system, which establishes the context and boundaries of the system to be modeled.
系统关系图系统(也称为0级 DFD)是资料流程图系统中的最高级别,只包含一个进程,代表整个系统,它建立了要建模的系统的上下文和边界。
The system context diagram (also known as a level 0 DFD) is the highest level in a data flow diagram and contains only one process, representing the entire system, which establishes the context and boundaries of the system to be modeled. It identifies the flows of information between the system and external entities (i.e. actors). A context diagram is typically included in a requirements document. It must be read by all project stakeholders and thus should be written in plain language, so the stakeholders can understand items
系统关系图系统(也称为0级 DFD)是资料流程图系统中的最高级别,只包含一个进程,代表整个系统,它建立了要建模的系统的上下文和边界。它识别系统和外部实体(即参与者)之间的信息流。上下文关系图通常包含在需求文档中。它必须被所有项目干系人阅读,因此应该用通俗易懂的语言来写,这样干系人才能理解项目
The objective of the system context diagram is to focus attention on external factors and events that should be considered in developing a complete set of systems requirements and constraints. A system context diagram is often used early in a project to determine the scope under investigation. Thus, within the document.
系统关系图的目标是关注在开发一套完整的系统需求和约束时应该考虑的外部因素和事件。在项目的早期,系统关系图通常被用来确定被调查的范围。因此,在文档中。
A system context diagram represents all external entities that may interact with a system. The entire software system is shown as a single process. Such a diagram pictures the system at the center, with no details of its interior structure, surrounded by all its External entities, interacting systems, and environments.
系统关系图代表所有可能与系统交互的外部实体。整个软件系统显示为一个单独的过程。这样的图表把系统画在中心,没有内部结构的细节,被所有的外部实体、交互系统和环境所包围。
系统关系图代表与系统交互的所有可能的外部实体与系统的关系,我们小组的实验室设备管理系统就可以通过系统关系图,将管理员,教师,学生,设备这些外部实体与系统相连构成系统关系图
Unified Modeling Language (UML)又称统一建模语言或标准建模语言。
UML 能帮我们做什么?
我们在进行项目的时候,通过使用 UML 的面向对象图的方式来更明确、清晰的表达项目中的架设思想、项目结构、执行顺序等一些逻辑思维。
UML 介绍:
1997年,OMG 组织(Object Management Group对象管理组织)发布了统一建模语言(Unified Modeling Language,UML)。UML 是一种编制软件蓝图的标准化语言,它的目标之一就是为开发团队提供标准通用的设计语言来开发和构建计算机应用。UML 提出了一套 IT 专业人员期待多年的统一的标准建模符号。通过使用UML,这些人员能够阅读和交流系统架构和设计规划。UML支持面向对象的技术,能够准确的方便地表达面向对像的概念,体现面向对象的分析和设计风格.
UML 统一了Booch、OMT、OOSE和其他面向对象方法所涉及的基本概念和建模符号。
UML的模型主要有三部分构成:
事物(Things):UML模型中最基本的构成元素,是具有代表性的成分的抽象
关系(Relationships):关系把事物紧密联系在一起
图(Diagrams ):图是事物和关系的可视化表示
UML 特点:
面向对象
可视化,表达能力强
独立于过程
独立于程序设计
容易掌握使用
在复杂需求中,UML图是非常必要的。用例图描述系统的外部交互、序列图描述系统的内部交互、状态图描述系统的动态特性、部署图描述系统的物理节点、类图与对象图描述依赖关系…所有的图都是协助团队策划稿能源更高效地厘清问题,掌握知识,高效解决问题的。试问下,在敏捷开发中,如果没有流程图、序列图、状态图进行辅助,你如何在代码过程中保证业务流程、系统前后端、多个系统切换开发做到敏捷高效?在敏捷开发时,面对稍复杂点的需求,如果要求团队提前用UML图厘清问题,后续填坑可以少很多。
A class is just a model like thing, which defines which members a class has and defines a class that does not allocate actual memory space to store it
类只是一个模型一样的东西,限定了类有哪些成员,定义出一个类并没有分配实际的内存空间来存储它
在UML的静态机制中类图是一个重点,它不但是设计人员关心的核心,更是实现人员关注的核心。建模工具也主要根据类图来产生代码。类图在UML的9个图中占据了一个相当重要的地位。
类的定义是:类是具有相似结构、行为和关系的一组对象的描述符。类是面向对象系统中最重要的构造块。类图显示了一组类、接口、协作以及他们之间的关系。在UML中问题域最终要被逐步转化,通过类来建模,通过编程语言构建这些类从而实现系统。类加上他们之间的关系就构成了类图,类图中还可以包含接口、包等元素,也可以包括对象、链等实例。接口在类图中通过版型来表示\<\\>,下面的介绍将主要介绍类,接口和类类似。
enterprise archirct11 类图中的元素都是从Toolbox中拖到class model 视图中的
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-VVIPr6Hr-1609755291774)(media/image6.png)]{width="2.9166666666666665in" height="3.2395833333333335in"}
UML 类图之package(包)
操作路径:Enterprise Archiect–>Class Model–>Add a package
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-x7WICCsJ-1609755291774)(media/image7.png)]{width=“3.4375in” height=“2.125in”}
UML类图之接口(Interface)
从左边的Toolbox中拖出一个Interface
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-EKNbrr2T-1609755291775)(media/image8.png)]{width=“5.428472222222222in” height=“3.5729166666666665in”}
修改Interface名称
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-l9l0s1zw-1609755291776)(media/image9.png)]{width=“1.46875in” height=“1.5729166666666667in”}
给Interface添加方法
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-p3qmQAz1-1609755291777)(media/image10.png)]{width=“6.572916666666667in” height=“5.3125in”}
Attributes:属性
Operations: 操作、方法
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-WRJqbdfL-1609755291778)(media/image11.png)]{width=“4.811805555555556in” height=“4.217361111111111in”}
Parameters: 方法参数
return:返回值
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-6hjcUhko-1609755291779)(media/image12.png)]{width=“1.46875in” height=“1.5729166666666667in”}
Interface在图上有《interface》标识,而Class没有标识。
UML类图之类(Class)
class中可以包含属性(特征)、方法(动作)
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-XAYsu7W0-1609755291780)(media/image13.png)]{width=“1.5104166666666667in” height=“3.0in”}
UML类图元素之间的关系
Realization(实现)
类实现了接口(Aniamal动物可以吃东西,那么就实现了Eatable接口)
Realization(实现)表示方式为: 空心三角+虚线
空心三角指向的是接口
虚线连接的是实现该接口的类
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-MNs8e3w2-1609755291781)(media/image14.png)]{width=“1.4791666666666667in” height=“3.125in”}
Generalization(泛化)
Generalization(泛化)表示方式为: 空心三角+实现
空心三角指向的是父类
实现连接的是子类
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-iBtloxfn-1609755291782)(media/image15.png)]{width=“2.5729166666666665in” height=“2.25in”}
Dependency(依赖)
Dependency(依赖)表示方式为: 箭头+虚线
Student,Teacher 类中的learn和teach方法,都需要参数类型为Book
所以说Student,Teacher依赖Book
类Student、Teacher中访问Book的属性和方法
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-KMkVTNWh-1609755291783)(media/image16.png)]{width=“3.4166666666666665in” height=“4.40625in”}
Aggregation(聚合)
Aggregation(聚合)的表示方式: 空心菱形+实线,空心菱形指向整体
说明:聚合关系是整体和个体的关系。下图Class是一个班级,但是学生可以离开班级而独立存在
班级Class 是整体,Student 是一个个体
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-xolT5Ers-1609755291783)(media/image17.png)]{width=“1.46875in” height=“2.875in”}
Composition(组合)
Composition(组合)的表示方法: 实心菱形+实线 实心菱形指向整体
说明: 组合也是关联关系的一种特例,他体现的是一种contains-a的关系,这种关系比聚合更强,也称为强聚合;他同样体现整体与部分间的关系,但此时整体与部分是不可分的,整体的生命周期结束也就意味着部分的生命周期结束;比如你和你的大脑;表现在代码层面,和关联关系是一致的,只能从语义级别来区分;
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-VpsdtNvx-1609755291784)(media/image18.png)]{width=“1.46875in” height=“2.7604166666666665in”}
Associate(关联)
Associate(关联)的表示方式: 箭头+实线,箭头指向被使用的类;
说明:类与类之间的联接,它使一个类知道另一个类的属性和方法,如下图所示:
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Z1sGxmCw-1609755291785)(media/image19.png)]{width=“1.46875in” height=“3.0520833333333335in”}
用类类型创建对象的过程,称为类的实例化
1. 类只是一个模型一样的东西,限定了类有哪些成员,定义出一个类并没有分配实际的内存空间来存储它
2. 一个类可以实例化出多个对象,实例化出的对象占用实际的物理空间存储类成员变量
3. 做个比方。类实例化出对象就像现实中使用建筑设计图建造出房子,类就像是设计图,只设计出需要什么东西,但是并没有实体的建筑存在,同样类也只是一个设计,实例化出的对象才能实际存储数据,占用物理空间。
类的大小即成员变量的大小
类对象中只保存了成员变量,成员函数只单独保存了一份
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-jUWeJLGl-1609755291786)(media/image20.png)]{width=“5.761805555555555in” height=“3.015972222222222in”}
Application domain (AppDomain) is a boundary established by the common language runtime around objects created within the same application scope (i.e., starting from the entry point of the application, anywhere along the sequence of object activation).
应用程序域 (application domain) (AppDomain) 一种边界,它由公共语言运行库围绕同一应用程序范围内创建的对象建立(即,从应用程序入口点开始,沿着对象激活的序列的任何位置)。
An application domain is a logical isolation boundary created around .NET applications so that applications do not access or affect each other. It is a light-weight process having its own set of code, data, and configuration settings. Application domains are created by the runtime hosts, which are invoked by the common language runtime (CLR) to load the applications that need to be executed.
Prior to .NET, the isolation boundary between applications was the processes in which they were loaded. Every process had its own private virtual memory and can not access the memory of another process directly. Application domain has features similar to that of a process.
Application domains have the following features:
应用程序域是在周围创建的逻辑隔离边界。NET 应用程序,使应用程序不访问或相互影响。它是一个有自己一套代码、数据和配置设置的轻量级进程。应用程序域是由运行时宿主创建的,运行时宿主被通用语言运行库调用来加载需要执行的应用程序。之前。NET 时,应用程序之间的隔离边界是加载它们的进程。每个进程都有自己的私有虚拟内存,不能直接访问另一个进程的内存。应用程序域具有类似于进程的特性。
应用程序域具有以下特性:
Optimum utilization of system resources by using fewer processes to execute multiple applications. 通过使用较少的进程执行多个应用程序来优化系统资源的利用
Reliability by using isolation of tasks in situations where data cannot be shared and for unstable tasks that need to be unloaded without affecting the process. 在数据不能共享的情况下使用任务隔离,对于需要卸载但不影响进程的不稳定任务,使用隔离的可靠性
Better efficiency by executing long-running processes that rarely use large extensions with optimal memory. 通过执行很少使用具有最佳内存的大型扩展的长时间运行的进程来提高效率
Application security by restricting the direct access to the code running in one application from the code or resources of another application. 通过限制从另一个应用程序的代码或资源直接访问在一个应用程序中运行的代码来实现应用程序安全性
Security control by specifying configuration details along for each application domain. 通过为每个应用程序域指定配置详细信息来进行安全控制
Application domain differs in the manner in which the CLR loads and executes multiple .NET applications in one single process. It does not allow direct access to the memory of loaded applications. It is managed by the CLR of the .NET Framework whereas a process is managed by the OS. The CLR provides fault isolation between application domains with less overhead than processes, due to its inherent feature of verifiable type-safety of managed code. Also, multiple threads can reside in an application domain, they are free to cross application domain boundaries.
For example, ASP.NET is a runtime host that creates multiple application domains for each user accessing a web site. They can also be created and configured for applications that need to isolate code or to load extensions only while using them. This fact makes application domains useful in situations where plug-ins and other untrusted code is used. They are also useful in minimizing the working set of applications that use large DLLs.
To enable communication between objects in different application domains one of the following three types of objects is used:
应用程序域的不同之处在于 CLR 加载和执行多个。NET 应用程序在一个进程中。它不允许直接访问已加载应用程序的内存。属性的 CLR 对其进行管理。NET 框架,而进程是由操作系统管理的。由于其固有的可验证托管代码类型安全特性,CLR 在应用程序域之间提供故障隔离,开销比进程少。此外,多个线程可以驻留在一个应用程序域中,它们可以自由地跨越应用程序域边界。例如,ASP.NET 是一个运行时主机,它为访问网站的每个用户创建多个应用程序域。还可以为需要隔离代码或仅在使用扩展时加载扩展的应用程序创建和配置这些扩展。这一事实使得应用程序域在使用插件和其他不可信代码的情况下非常有用。它们在最小化使用大型 dll 的应用程序的工作集方面也很有用。为了支持不同应用程序域中的对象之间的通信,需要使用以下三种类型的对象之一:
Marshal-By-Value: Complete copy of the object passed to the calling application domain. This is used when the state of object can be moved for performance reasons. 按值封送: 传递给调用应用程序域的对象的完整副本。当出于性能原因可以移动对象状态时,可以使用这种方法
Marshal-By-Reference-Reference (MBR): A proxy of the object is passed to the client; used when the state of the object has to stay within the application domain. 按引用封送(marshal-by-reference,MBR) : 将对象的代理传递给客户机; 当对象的状态必须保留在应用程序域中时使用
Context-bound: MBR object used across domains or within the context of its own application domain. 上下文绑定: 跨域或在自己的应用程序域上下文中使用的 MBR 对象
Activity diagram is another common tool used by UML to model the dynamic behavior of a system. It describes the sequence of activities and shows the control flow from one activity to another. Activity diagram is a kind of flow chart in essence. Activity diagram focuses on the control flow from one activity to another, which is driven by internal processing.
活动图是UML用于对系统的动态行为建模的另一种常用工具,它描述活动的顺序,展现从一个活动到另一个活动的控制流。活动图在本质上是一种流程图。活动图着重表现从一个活动到另一个活动的控制流,是内部处理驱动的流程。
Activity Diagrams describe how activities are coordinated to provide a service which can be at different levels of abstraction. Typically, an event needs to be achieved by some operations, particularly where the operation is intended to achieve a number of different things that require coordination, or how the events in a single use case relate to one another, in particular, use cases where activities may overlap and require coordination. It is also suitable for modeling how a collection of use cases coordinate to represent business workflows
活动图描述了如何协调活动以提供处于不同抽象层次的服务。通常,一个事件需要通过一些操作来实现,特别是当操作的目的是实现一些需要协调的不同的事情时,或者单个用例中的事件如何相互关联,特别是活动可能重叠并需要协调的用例。它还适合于建模用例集合如何协调以表示业务工作流
Identify candidate use cases, through the examination of business workflows 通过检查业务工作流,识别候选用例
Identify pre- and post-conditions (the context) for use cases 确定用例的前置条件和后置条件(上下文)
Model workflows between/within use cases 用例中/之间的模型工作流
Model complex workflows in operations on objects 为对象操作中的复杂工作流建模
Model in detail complex activities in a high level activity Diagram 在高级活动图中详细建模复杂的活动
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Z8OjsHb9-1609755291787)(media/image21.png)]{width=“3.7118055555555554in” height=“4.451388888888889in”}
活动图和交互图是UML中对系统动态方面建模的两种主要形式
•交互图强调的是对象到对象的控制流,而活动图则强调的是从活动到活动的控制流
•活动图是一种表述过程基理、业务过程以及工作流的技术。它可以用来对业务过程、工作流建模,也可以对用例实现甚至是程序实现来建模
•UML 2.0而言,去除了"活动图是状态图的一种特例"这一规定
【用途】活动图是UML用于对系统的动态行为建模的另一种常用工具,它描述活动的顺序,展现从一个活动到另一个活动的控制流。活动图在本质上是一种流程图。活动图着重表现从一个活动到另一个活动的控制流,是内部处理驱动的流程。
A decision table is a table with various conditions and their corresponding actions .
决策表是一个包含各种条件及其相应操作的表。
Decision tree is a two dimensional matrix. It is divided into four parts, condition stub, action stub, condition entry, and action entry . See the first figure listed below. Condition stub shows the various possible conditions.
决策表是一个包含各种条件及其相应操作的表。决策树是一个二维矩阵。它分为四个部分,条件存根,行动存根,条件入口和行动入口。参见下面列出的第一个图。条件存根显示了各种可能的条件。
Condition entry is used for specifying which condition is being analyzed. Action stub shows the various actions taken against different conditions.
条件条目用于指定正在分析的条件。动作存根显示了针对不同条件所采取的各种动作。
And action entry is used to find out which action is taken corresponding to a particular set of conditions.
动作条目用于查找对应于一组特定条件的动作。
The steps to be taken for a certain possible condition are listed by action statements. Action entries display what specific actions to be undertaken when selected conditions or combinations of conditions are true. At times notes are added below the table to indicate when to use the table or to distinguish it from other decisions tables.
对于某种可能的条件所采取的步骤由操作语句列出。动作条目显示当选定的条件或条件组合为真时要执行的特定动作。有时在表的下面添加注释,以指示何时使用该表或将其与其他决策表区分开来。
The right side columns of the table link conditions and actions and form the decision rules hence they state the conditions that must be fulfilled for a particular set of actions to be taken. In the decision trees, a fixed ordered sequence is followed in which conditions are examined. But this is not the case here as the decision rule incorporates all the required conditions, which must be true.
表的右侧列链接了条件和操作,并形成了决策规则,因此它们说明了要采取的一组特定操作必须满足的条件。在决策树中,一个固定的有序序列被遵循,其中条件被检查。但是这里的情况并非如此,因为决策规则包含了所有必需的条件,而这些条件必须是真实的。
Before describing the steps involved in building the decision table it is important to take a note of few important points. Every decision should be given a name and the logic of the decision table is independent of the sequence in which condition rules are written but the action takes place in the order in which events occur . Wherever possible, duplication of terms and meaning should be avoided and only the standardized language must be used.
在描述构建决策表所涉及的步骤之前,重要的是要注意几个要点。每个决策都应该被赋予一个名称,决策表的逻辑与条件规则的编写顺序无关,但是操作是按照事件发生的顺序进行的。应尽可能避免术语和意义的重复,只使用标准语言。
The steps of building the concerned tables are given below.
建立有关表格的步骤如下。
Firstly figure out the most essential factors to be considered in making a decision.
This will identify the conditions involved in the decision. Only those conditions should be selected which have the potential to either occur or not but partial occurrences are not permissible.
首先找出在做决定时要考虑的最重要的因素。这将确定该决定所涉及的条件。只应选择有可能发生或不发生但不允许部分发生的条件。
Determine the most possible steps that can take place under varying conditions and not just under current condition. This step will identify the actions.
确定最可能的步骤,可以发生在不同的条件下,而不只是在目前的条件下。这一步将识别行动。
Calculate all the possible combinations of conditions.
For every N number of conditions there are 2*2*2… (N times) combinations to be considered.
计算所有可能的条件组合。对于每 n 个条件,有2 * 2 * 2… … (n 次)组合需要考虑。
Fill the decision rules in the table.
Entries in a decision table are filled as Y/N and action entries are generally marked as “X” . For the conditions that are immaterial(不重要的,无关紧要的) a hyphen “-” is generally put. Decision table is further simplified by eliminating and consolidating certain rules. Impossible rules are eliminated(排除). There are certain conditions whose values do not affect the decision and always result in the same action. These rules can be consolidated into(统一放到) a single rule.
填写表中的决策规则。决策表中的条目填充为 y/n,操作条目通常标记为" x"。对于非物质的条件(something something something something,something something something something something) ,通常用连字符"-"表示。通过删除和合并某些规则,进一步简化了决策表。不可能的规则被消除(something something)。有些条件的值不会影响决策,并且总是导致相同的行为。这些规则可以合并成(something something something something)一个规则。
VSphere fault tolerance ensures the continuous availability of the virtual machine by creating and maintaining the secondary virtual machine that is the same as the primary virtual machine and can replace the primary virtual machine at any time in case of failure. In fact, it creates an identical replica for a virtual machine.
vSphere Fault Tolerance通过创建和维护与主虚拟机相同,并且可在发生故障切换时随时替换主虚拟机的辅助虚拟机,来确保虚拟机的连续可用性,其实就是一为某一个虚拟机创建一个完全相同的副本。
vSphere Fault Tolerance通过创建和维护与主虚拟机相同,并且可在发生故障切换时随时替换主虚拟机的辅助虚拟机,来确保虚拟机的连续可用性,其实就是一为某一个虚拟机创建一个完全相同的副本。可以为虚拟机启用vSphere Fault Tolerance。比获得比vSphere HA所提供的级别更高的可用性和数据保护,从而确保业务连续性。Fault Tolerance时基于ESXi主机平台构建的(使用VMware vLockstep技术),它通过在单独主机上一虚拟锁步方式运行相同的虚拟机来提供连续可用性。
使用FT技术,允许虚拟机在无须中断的情况下从服务器故障恢复,实现零停机时间和零数据丢失。基于vLockstep技术,该技术时主虚拟机和辅助虚拟机保持虚拟同步运行。VMware FT独立于应用程序和操作系统,允许以更低的成本和复杂性保护更多应用程序,并且可以和其他的vSphere功能集成。
vSphere中的FT
vSphere HA通过在主机出现故障时重新启动虚拟机来为虚拟机提供基本级别的保护。vSphere FT可提供更高级别的可用性,允许用户对任何虚拟机运行保护以防止主机发生故障时丢失数据、事务或连接。FT通过确保主虚拟机和辅助虚拟机的状态在虚拟机的指令执行的任何时间点均相同来提供连续可用性。使用ESXi平台上的额VMware vLockstep技术来完成此过程。vLockstep通过使主虚拟机和辅助虚拟机执行相同顺序的X86指令来完成此过程。主虚拟机捕获所有输入和事件(从处理器到虚拟I/O设备),并在辅助虚拟机上进行重放。辅助虚拟机执行与主虚拟机相同的指令序列,而仅单个虚拟机映像(主虚拟机)执行工作负载。如果运行主虚拟机的主机或运行辅助虚拟机的主机发生故障,则会发生即时且透明的故障切换。正常运行的ESXi主机将无缝变成主虚拟机的主机,而不会断开网络连接或中断正在处理的事务。使用透明故障切换,不会有数据损失,并且可以维护网络连接。在进行透明故障切换之后,将重新生成新的辅助虚拟机,并且将重新建立冗余。整个过程是透明且全自动的,并且即使vCenter Server不可用,也会发生。
vSphere FT的工作方式
VMware 容错可通过创建和维护等同于主虚拟机并可在发生故障切换时替换主虚拟机的辅助虚拟机来为虚拟机提供连续可用性。当启用Fault Tolerance时,会创建一个重复虚拟机(称为辅助虚拟机),该虚拟机会以虚拟锁步方式随主虚拟机一起运行。VMware vLockstep可捕获主虚拟机上发生的输入和事件,并将这些输入和事件发送到正在另一个主机上运行的辅助虚拟机。使用此信息,辅助虚拟机的执行将等同于主虚拟机的执行。因为辅助虚拟机与主虚拟机一起以虚拟锁步的方式运行,所以它可以无中断地接管任何点处的执行,从而提供容错保护(三)vSphere FT的要求
在使用FT之前,必须满足的要求包括群集要求、主机要求、虚拟机要求和硬件要求。
群集要求:至少有两台通过FT认证的主机运行相同的FT版本号或主机内部版本号,如FT版本:2.0.1-3.0.0-3.0.0.ESXi主机可以访问相同的虚拟机数据存储和网络,配置了FT日志记录和vMotion网络,vSphere HA群集已创建并启用。
主机要求:主机上的物理处理器必须来自与FT兼容的处理器组。要确认群集内的主机是否兼容,从而判断其是否支持FT。
虚拟机要求:虚拟机文件必须存储在共享存储上。可接受共享的存储解决方案包括光纤通道、(硬件和软件)iSCSI、NFS和NAS。虚拟机必须存储在虚拟RDM或厚置备的虚拟机磁盘(VMDK)文件(已启用"群集功能"选项)中。虚拟机必须在一个受制裁的客户机操作系统上运行。
这是一个关于虚拟机与容错性的词语,通过它可以恢复服务器的故障,在我们小组的项目中暂时不考虑使用到虚拟机,但是其关于容错性的内容是值得我们学习和借鉴的
A linear programming model used by enterprises to realize management by objectives. Fenghuoliepin company believes that goal planning is an effective method to solve the multi-objective management of enterprises. It is a mathematical method to find the solution with the minimum deviation from the target value under the given limited resources according to the target values determined by the decision-maker in advance and their realization priorities.
企业用来实现目标管理的一种线性规划模型。烽/火猎聘公司认为目标规划是解决企业多目标管理的有效方法,它是按照决策者事前确定的若干目标值及其实现的优先次序,在给定的有限资源下寻找偏离目标值最小的解的数学方法。
美国学者A.查纳斯和W.W.库珀在把线性规划应用于企业时,认识到企业经营具有多目标的特点,因而在1961年首先提出了目标规划的概念和数学模型。目标规划的基本概念是,当规定的目标与求得的实际目标值之间的差值为未知时,可用偏差量 d来表示。d表示实际目标值超过规定目标值的数量,称为正偏差量,d表示实际目标值未达到规定目标值的数量,称为负偏差量。
如果企业决策者将利润量、材料消耗量、能源消耗量等可控指标作为目标时,则可根据各项指标的完成对企业经营活动作出贡献的重要程度,分别给这些目标以不同的优先级别pk,k=1,2,…,K。如果规定利润最重要,则确定为p1;材料消耗量次之,则确定为p2等等。p1优先于p2,p2优先于p3等等。在同一优先级别中也可以同时有几个目标。在进行目标规划时凡是给予优先级别p1的目标,应首先实现,在此基础上再相继实现p2 、p3等级别的相应目标。最后使未能达到目标值的偏差量总和为最小。
Portability is a characteristic attributed to a computer program if it can be used in an operating systems other than the one in which it was created without requiring major rework.
可移植性是计算机程序的一个特征,如果它可以用在操作系统之外的其他操作系统中,而不需要大量的返工。
Portability is a characteristic attributed to a computer program if it can be used in an operating systems other than the one in which it was created without requiring major rework. Porting is the task of doing any work necessary to make the computer program run in the new environment. In general, programs that adhere to standard program interfaces such as the X/Open UNIX 95 standard C language interface are portable. Ideally, such a program needs only to be compiled for the operating system to which it is being ported. However, programmers using standard interfaces also sometimes use operating system extensions or special capabilities that may not be present in the new operating system. Uses of such extensions have to be removed or replaced with comparable functions in the new operating system. In addition to language differences, porting may also require data conversion and adaptation to new system procedures for running an application.
可移植性是计算机程序的一个特征,如果它可以用在操作系统之外的其他操作系统中,而不需要大量的返工。移植的任务是完成任何必要的工作,使计算机程序在新的环境中运行。一般来说,遵循标准程序接口(如 x/Open UNIX 95标准 c 语言接口)的程序是可移植的。理想情况下,这样的程序只需要为它要移植到的操作系统进行编译。然而,使用标准接口的程序员有时也使用操作系统扩展或新操作系统中可能没有的特殊功能。必须在新的操作系统中删除或用类似的功能取代这种扩展的用途。除了语言上的差异,移植还可能需要数据转换和适应运行应用程序的新系统过程。
Portability has usually meant some work when moving an application program to another operating system. Recently, the Java programming language and rudiment environment has made it possible to have programs that run on any operating system that supports the Java standard (from Sun Micro systems) without any porting work. Java applets in the form of compiler byte code can be sent from a server program in one operating system to a client program (your Web browser) in another operating system without change.
在将应用程序移动到另一个操作系统时,可移植性通常意味着一些工作。最近,Java 编程语言和执行期函式库语言使程序可以在任何支持 Java 标准的操作系统上运行(来自昇阳电脑) ,而不需要任何移植工作。预编译字节码形式的 Java 小程序可以从一个操作系统中的服务器程序发送到另一个操作系统中的客户机程序(您的 Web 浏览器) ,而不需要更改。
对于一些大型系统来说,可移植性显得尤为重要,因为在一定程度上可移植性与可维护性挂钩,除此之外,我们可以使用的设备越来越多,手机,电脑,不同设备也有不同的操作系统,要想让我们开发出来的系统更易于使用,使用者更方便,那么可移植性也是必不可少的。
Quality requirement is a common term in project management. It is defined as the condition used to assess the conformance of the project by validating the acceptability of an attribute or characteristic for the quality of a particular result.
质量要求是项目管理中的一个通用术语。它被定义为通过验证特定结果质量的属性或特征的可接受性来评估项目一致性的条件。
In a nutshell, the quality requirement defines the expectations of the customer for quality, the internal processes as well as the attributes of products that indicate whether the quality factors are satisfied or not.
简而言之,质量要求定义了顾客对质量的期望,内部过程以及产品的属性,这些属性表明了质量要素是否得到满足。
The quality requirements in project management are defined in terms of the quality criteria, quality factors, and quality metrics. The quality criteria document the internal process and attributes of the product that will be monitored all throughout the project life cycle. The quality factors document the perceived aspects of the user regarding the deliverables of the project to determine if the project satisfies the expectations from customers. Lastly, the quality metrics document the indicators used to measure the quality of the product.
项目管理中的质量要求是根据质量标准、质量因素和质量度量来定义的。质量标准记录了产品的内部过程和属性,这些过程和属性将在整个项目生命周期中受到监控。质量因素记录用户对项目可交付成果的感知方面,以确定项目是否满足客户的期望。最后,质量度量文件的指标用来衡量产品的质量。
The quality requirement is used by different project management processes particularly the Quality Management Plan to create the risk register, requirements documentation, and cost-benefit analysis.
质量要求被不同的项目管理过程使用,尤其是质量管理计划,用来创建风险登记册、需求文档和成本-收益分析。
This term is defined in the 5th edition of the PMBOK.
软件质量需求分类
用于确定测试目标
测试目标包括
功能、性能、界面、易用性、兼容性、安全性、可用性 / 可靠性、维护性、可扩展性
功能以外统称为 非功能
功能
软件能做什么
需要做什么
怎么做是正确的
那些功能要测试、哪些是不需要测试的
性能
反应软件运行时的效率和占用资源情况的能力(速度)
时间特性:时间短、速度快、效率高
资源特性:占用资源(CPU 、内存 、硬盘、网络)少
界面(UI)
user interface()好不好看
布局合理
控件位置恰当
文字没有乱码、字体大小合适
颜色使用恰当
图片、表格恰当、舒适、美观
易用性
符不符合用户平时使用的习惯
指定条件下使用时,软件产品被理解、学习、使用和吸引用户的能力
尽量符合用户平时的使用习惯(比如确认enter 换行什么的)
兼容性 / 可移植性
指产品从一种环境迁移到另一个环境中的能力,反应一个软件与不同的硬件环境、操作平台、其他软件的共同使用能力
硬件 :CPU 不同性能(HZ)
平台: win7 win10
软件自身的不同版本
其他软件兼容 :360 和 QQ ,数据库升级更变,不同浏览器使用
数据兼容: 不同网络状态
安全性
软件产品保护信息和数据的能力
可用性 / 可靠性
指系统正常运行的能力或程度,
可行性=正常运行时间 / (正常运行时间 + 非正常运行时间) x 100%
可用性指标一般要达到
4个9,即 99.99%(全年52分钟不正常工作)
5个9,即99.999%(全年5分钟)
7个9 ,即99.99999%(全年失效时间不超过两秒)
一般测试时间不足,可以采用空间换时间的方法,如:在高负载情况下进行为期一周或一个月的测试,以判断可靠性
关注 MTTF (平均无故障时间) 、 MTTR(平均回复时间、MTBF(平均失效时间间隔))
可维护性
做软件的可被修复的能力(打补丁一类)
修改可能包括修正值、改进或者软件对环境锁需求的功能规格说明变化的适应
可维护性的软件应该是易改变的、稳定的、易测试的
可扩展性 / 可伸缩性测试
通过少量的改动就可以实现整个系统处理能力的zengzhang
如部署两台服务器时测试系统性能(容量,即最大负载),在部署四台、八台服务器时分别进行系统容量的测试,看其容量是否为上次(两台、四台)实验值的两倍或者接近两倍。如果是,则系统就具有良好的可伸缩性
(NFR) specifies the quality attribute of a software system. They judge the software system based on Responsiveness, Usability, Security, Portability and other non-functional standards that are critical to the success of the software system. Example of nonfunctional requirement, “how fast does the website load?” Failing to meet non-functional requirements can result in systems that fail to satisfy user needs.
非功能性需求指定了软件系统的质量属性。他们根据对软件系统成功至关重要的响应能力、可用性、安全性、可移植性和其他非功能性标准来判断软件系统。非功能性需求的例子,"网站加载的速度有多快? "不能满足非功能性需求可能导致系统不能满足用户需求。
Non-functional Requirements allows you to impose constraints or restrictions on the design of the system across the various agile backlogs. Example, the site should load in 3 seconds when the number of simultaneous users are > 10000. Description of non-functional requirements is just as critical as a functional requirement.
非功能性需求允许您在各种敏捷积压中对系统设计施加约束或限制。例如,当同时用户数大于10000时,站点应该在3秒内加载。非功能性需求的描述与功能性需求一样重要。
下面是一些非功能性需求的例子:
Users must change the initially assigned login password immediately after the first successful login. Moreover, the initial should never be reused. 用户必须在第一次成功登录后立即更改最初分配的登录密码。此外,初始化的代码永远不应该被重用
Employees never allowed to update their salary information. Such attempt should be reported to the security administrator. 员工不允许更新他们的工资信息。这种尝试应该报告给安全管理员
Every unsuccessful attempt by a user to access an item of data shall be recorded on an audit trail. 用户每次尝试访问一个数据项目的失败都应记录在审计线索上
A website should be capable enough to handle 20 million users with affecting its performance 一个网站应该能够处理影响其性能的2000万用户
The software should be portable. So moving from one OS to other OS does not create any problem. 软件应该是可移植的,所以从一个操作系统移动到另一个操作系统不会产生任何问题
Privacy of information, the export of restricted technologies, intellectual property rights, etc. should be audited. 应对信息隐私、受限技术出口、知识产权等进行审计
非功能测试的好处如下:
The nonfunctional requirements ensure the software system follow legal and compliance rules. 非功能性需求确保软件系统遵循法律和遵从规则
They ensure the reliability, availability, and performance of the software system 它们确保了软件系统的可靠性、可用性和性能
They ensure good user experience and ease of operating the software. 他们确保良好的用户体验和易于操作的软件
They help in formulating security policy of the software system. 它们有助于制定软件系统的安全策略
非功能性要求的缺点如下:
None functional requirement may affect the various high-level software subsystem 无功能需求可能影响各种高级软件子系统
They require special consideration during the software architecture/high-level design phase which increases costs. 它们需要在软件架构/高级设计阶段特别考虑,这会增加成本
Their implementation does not usually map to the specific software sub-system, 它们的实现通常不会映射到特定的软件子系统,
It is tough to modify non-functional once you pass the architecture phase. 一旦通过了体系结构阶段,就很难修改非功能性的内容
Interface is a 100% abstract class. It contains only constants and method signatures. In other words it is a reference type similar to class. An interface can’t be instantiated. It can be implemented by a class or extended by another interface.
接口是100% 抽象类。它只包含常量和方法签名。换句话说,它是类似于 class 的引用类型。接口不能被实例化。它可以通过类实现,也可以通过其他接口进行扩展。
An interface can be defined as the following:
接口可以定义如下:
public interface DriveCar {
void turnLeft();
void turnRight();
void moveBack();
void accelerate();
}
The methods declared in an interface don’t have method bodies. By default all the methods in an interface are public abstract. Similarly all the variables we define in an interface are essentially constants because they are implicitly public static final. So, the following definition of interface is equivalent to the above definition.
在接口中声明的方法没有方法体。默认情况下,接口中的所有方法都是公共抽象。类似地,我们在接口中定义的所有变量本质上都是常量,因为它们是隐式的公共静态末尾。因此,下面的接口定义等价于上面的定义。
public interface DriveCar {
public abstract void turnLeft();
public abstract void turnRight();
public abstract void moveBack();
public abstract void accelerate();
}
How To Use:
如何使用:
An interface defines a contract which an implementing class must adhere to. The above interface DriveCar defines a set of operations that must be supported by a Car. So, a class that actually implements the interface should implement all the methods declared in the interface.
接口定义了实现类必须遵守的契约。上面的接口 DriveCar 定义了一组必须由 Car 支持的操作。因此,实际实现接口的类应该实现接口中声明的所有方法。
Example:
例子:
class Car implements DriveCar{
void turnRight(){
//implementation code goes here
}
void turnLeft(){
//implementation code goes here
}
void moveBack(){
//implementation code goes here
}
void accelerate(){
//implementation code goes here
}
}
Now we can take a reference of type DriveCar and assign an object of Car to it.
这是java的基础,需要学习掌握
Requirements analysis, also called requirements engineering, is the process of determining user expectations for a new or modified product. These features, called requirements, must be quantifiable, relevant and detailed.
需求分析,也称为需求工程,是确定用户对新产品或修改后产品的期望的过程。这些特性,即所谓的需求,必须是可量化的、相关的和详细的。
Requirements analysis, also called requirements engineering, is the process of determining user expectations for a new or modified product. These features, called requirements, must be quantifiable, relevant and detailed. In software engineering, such requirements are often called functional specifications. Requirements analysis is an important aspect of project management.
需求分析,也称为需求工程,是确定用户对新产品或修改后产品的期望的过程。这些特性,即所谓的需求,必须是可量化的、相关的和详细的。在软件工程中,这样的需求通常被称为功能规范。需求分析是项目管理的一个重要方面。
Requirements analysis involves frequent communication with system users to determine specific feature expectations, resolution of conflict or ambiguity in requirements as demanded by the various users or groups of users, avoidance of feature creep and documentation of all aspects of the project development process from start to finish. Energy should be directed towards ensuring that the final system or product conforms to client needs rather than attempting to mold user expectations to fit the requirements.
需求分析涉及与系统用户的频繁沟通,以确定具体的特性期望、解决冲突或需求的模糊性,以满足不同用户或用户组的要求、避免特性蔓延以及从开始到结束的项目开发过程的所有方面的文档化。能源应该用于确保最终的系统或产品符合客户的需要,而不是试图塑造用户的期望以适应需求。
Requirements analysis is a team effort that demands a combination of hardware, software and human factors engineering expertise as well as skills in dealing with people.
需求分析是一个团队工作,需要硬件、软件和人因工程专业知识以及与人打交道的技能的组合。
Abnormal End (ABEND) is an abnormal or unexpected termination of a task in software. It occurs when a software program crashes due to errors. Generally errors in a software application or the operating system cause ABEND.
异常结束(ABEND)是软件中任务的异常或意外终止。当一个软件程序由于错误而崩溃时,就会发生这种情况。通常,软件应用程序或操作系统中的错误会导致 ABEND。
The term ABEND gets its name from an error message seen in IBM OS/360 systems. The term is claimed to have derived from the German word “abend”, which means “evening”. When an ABEND occurs the system may stop responding, causing the program to close abruptly.
An ABEND may occur in two scenarios:
术语 ABEND 的名称来自 IBM OS/360系统中的一条错误消息。据称,这个词来源于德语" abend" ,意思是"傍晚"。当 ABEND 发生时,系统可能停止响应,导致程序突然关闭。ABEND 可能发生在两种情况下:
When the system is given a set of instructions that it cannot handle or recognize 当系统接收到一系列的指令,而这些指令又不能处理或识别
When a program tries to address a memory space beyond a specific limit 当程序试图寻址超出特定限制的内存空间时
Modern operating systems are designed to prevent the system from rebooting by allowing only the offending application to halt or close. Other applications will continue to run normally. Modern operating systems are also more bug resistant than their predecessors, but some application bugs do cause the operating system to hang or lock up, requiring a reboot.
现代操作系统的设计目的是防止系统重启,只允许有问题的应用程序暂停或关闭。其他应用程序将继续正常运行。现代操作系统也比它们的前辈更能抵抗 bug,但是一些应用程序的 bug 确会导致操作系统挂起或锁定,需要重新启动。
异常结束在软件开发和使用过程中时十分常见的现象,几乎是无法避免的,原因可能有很多种,我们应尽可能得去规避和想办法处理这些异常
Absolute address of memory refers to an address scheme in communication, computer and data processing system. This address directly identifies a storage unit without using the associated media, such as a base station address or a related address.
存储器的绝对地址(Absolute Address)是指在通信、计算机和数据处理系统中的一个地址方案。这个地址直接鉴别一个存储单元而不使用相关媒体,例如,一个基站地址或相关地址。
Absolute address is actually a term used when referring to one of the addressing modes used by an application. Thus, in a computer that offers virtual memory, this ‘absolute address’ is also a virtual address - because all application code is only going to refer to virtual addresses. Other addressing modes use virtual addresses as well. Of course, like I wrote earlier, virtual addresses are eventually mapped to a physical addresses when accessing RAM.
绝对地址实际上是在引用应用程序使用的寻址模式时使用的术语。因此,在提供虚拟内存的计算机中,这个"绝对地址"也是一个虚拟地址------因为所有应用程序代码都只引用虚拟地址。其他寻址模式也使用虚拟地址。当然,正如我前面所写的,当访问 RAM 时,虚拟地址最终会映射到物理地址。
Here is how an ‘absolute address’ is different from it’s counterparts - the other addressing modes (one of them being ‘relative address’):
以下是"绝对地址"与其他寻址方式(其中一种是"相对地址")的区别:
An Intel JMP(jump) instruction may specify a ‘relative jump’, where the displacement is relative to the next instruction. Something like:
一条 Intel JMP (跳转)指令可能指定一个"相对跳转" ,其位移相对于下一条指令。例如:
“Jump N bytes ahead of the next instruction” <- This is PC-relative addressing.
“跳转 n 字节前面的下一个指令” <-这是 pc 相对寻址。
Or it may be used with an absolute address, like:
或者可以和绝对地址一起使用,比如:
“Jump to the Nth byte in memory” <- This is absolute addressing.
“跳转到内存中的第 n 个字节” <-这是绝对地址。
In both cases, the addresses being referred to by the JMPs are virtual addresses (which get mapped to a physical address in a way that is transparent to the application)
在这两种情况下,jmp 引用的地址都是虚拟地址(以对应用程序透明的方式映射到物理地址)
在互联网上绝对地址由IP4规则构成,共4组数字每组数字从0~255,由"."号间隔,格式为XXX.XXX.XXX.XXX,此数组为互联网上的独立地址,在任何网站通过这个地址可以直接到达目标网页,包含主域名和目录地址。
在数据传输和存储中主存储器的存储单元以字节为单位,每个存储单元都有一个地址与其对应,假定主存储器的容量为n,则该主存储器就有n个存储单元(既n个字节的存储空间),其地址编号为:0,1,2,…,n-1。把主存空间的地址编号称为主存储器的绝对地址,与绝对地址对应的主存空间称为物理地址空间。
绝对地址的概念属于计算机的基础知识。
Abstract machines, also called automata, are an element of theoretical computer science. An abstract machine resembles a function in mathematics.
抽象机器,又称自动机,是理论计算机科学的一个组成部分。
Abstract machines, also called automata, are an element of theoretical computer science. An abstract machine resembles a function in mathematics. It receives inputs and produces outputs according to specified rules. Abstract machines differ from more literal machines because they are assumed to function perfectly and independently from hardware. They are subdivided into types on the basis of characteristics such as how they perform their operations and what types of inputs they can receive.
抽象机器,又称自动机,是理论计算机科学的一个组成部分。抽象机器类似于数学中的函数。它接收输入并根据指定的规则生成输出。抽象机器不同于更多的文字机器,因为它们被假定为功能完美且独立于硬件。根据它们如何执行其操作以及它们可以接收到什么类型的输入等特征,它们又被细分为几种类型。
When classifying abstract machines, one of the most simple distinctions concerns the number of operations they are permitted to perform at any given point. An abstract machine is called deterministic if there is always only one way for it to proceed. It is nondeterministic if multiple possibilities exist for the machine in at least one of its possible states. A “pushdown” automaton is one that has the capacity to manipulate its stack of inputs, rather than simply responding to them one by one in the order in which they appear.
在对抽象机器进行分类时,最简单的区别之一是允许它们在任意给定点执行的操作数。如果抽象机器只有一种运行方式,那么它就被称为确定性机器。如果机器处于至少一种可能状态时存在多种可能性,那么它是不确定的。"下推"自动机具有操作其输入堆栈的能力,而不是简单地按输入出现的顺序逐个响应它们。
Wolfram MathWorld gives two famous examples of abstract machines. One of these examples is Conway’s game of life, which is a deterministic abstract machine because only one configuration can emerge out of any other. This game uses a grid in which each box, or cell, can either have the state “living” or “dead.” The state of the whole grid is determined on the basis of the previous state. If a living cell touches exactly two or three other living cells, it continues to live. If it has one, two, or more than three neighbors (up to a possible eight), it dies. A dead cell with exactly three neighbors will come to life; otherwise, it will remain dead.
MathWorld 给出了两个著名的抽象机器的例子。其中一个例子是康威的生命游戏,这是一个确定性的抽象机器,因为只有一个配置可以出现在任何其他。这个游戏使用一个网格,其中每个盒子,或细胞,可以有状态"活着"或"死亡"整个网格的状态是根据以前的状态确定的。如果一个活细胞恰好与另外两个或三个活细胞接触,它就会继续存活。如果它有一个、两个或三个以上的邻居(最多可能有八个) ,它就会死亡。一个正好有三个邻居的死亡细胞会复活,否则,它会一直死亡。
Another example, the Turing machine, is one of the most basic and fundamental abstract machines in computer science. A Turing machine performs operations on a tape—a string of symbols—of unlimited size. It contains instructions both for changing the symbols and for changing the symbol upon which it is operating. A simple Turing machine might have only the instruction “transform symbol to 1, then move right.” This machine would output nothing but a string of 1’s. This simple Turing machine is deterministic, but it is also possible to construct nondeterministic Turing machines that can perform several different operations given the same input.
另一个例子,图灵机,是计算机科学中最基本和最基本的抽象机器之一。图灵机在一个磁带(一串符号)上执行无限大小的操作。它包含了改变符号和改变其上运行的符号的指令。一个简单的图灵机可能只有"转换符号为1,然后向右移动"的指令这台机器只能输出1的字符串。这个简单的图灵机是确定性的,但是也可以构造不确定的图灵机,它可以在相同的输入下执行多个不同的操作。
These abstract machines can serve many purposes. They can be fun theoretical toys, but they can also serve as models for real computer systems. The abstract machine is at the heart of computer science as a discipline.
这些抽象的机器可以达到许多目的。他们可以是有趣的理论玩具,但他们也可以作为真正的计算机系统的模型。抽象机器是计算机科学作为一门学科的核心。
In the realm of management, an action item is a specific task or action that needs to be taken care of, and they are usually what you would place on a to-do list or a calendar so that you can keep track of what needs to be done.
在管理领域,行动项目是一项需要处理的具体任务或行动,它们通常是你将要放在待办事项列表或日历上的内容,以便你能够跟踪需要做的事情。
If you have ever kept a planner or to-do list, then you have probably used action items. An action item is a single, clearly defined task that must be done. For example, a personal action item could be to walk the dog or to call mom. While action items help you keep track of and accomplish the things you need to accomplish in your daily life, they have a bigger importance in the workplace.
如果你曾经保留过一个计划表或待办事项清单,那么你可能已经使用过行动项目。一个行动项目是一个单一的,明确定义的任务,必须完成。例如,一个个人行动项目可以是遛狗或者打电话给妈妈。虽然行动项目可以帮助你在日常生活中追踪和完成你需要完成的事情,但是它们在工作场所有更大的重要性。
If you owned your own business and wanted to grow your business, then you’d need to implement action items to keep you on track. Action items help you figure out what you need to do to get a project from start to finish. Breaking a project down into more tangible, bite-sized steps can make a large project seem that much easier to complete.
如果你拥有自己的企业,想要发展自己的业务,那么你就需要实施行动项目,以保持你在正轨上。行动项目可以帮助你弄清楚从开始到完成一个项目需要做些什么。将一个项目分解成更具体、小步骤可以使一个大项目看起来更容易完成。
Action items help break a big project into smaller, more manageable tasks 行动项目有助于将一个大项目分解成更小、更易于管理的任务
action items
When to Use Them
何时使用它们
Imagine that you do have your own business. You have a business that makes tablets and laptops, and you are about to start a project to design a new laptop/tablet combo. When should you start to use action items?
想象一下你有自己的生意。你有一个生产平板电脑和笔记本电脑的企业,你将要开始一个设计新的笔记本电脑/平板电脑组合的项目。你应该什么时候开始使用行动项?
You should use action items from the beginning of the project. Even if you are in the planning stages, action items will help you get to the next step and figure out what you need to do.
您应该从项目的开始就使用操作项。即使你正处于计划阶段,行动项目也会帮助你进入下一步,弄清楚你需要做什么。
You should also use action items throughout your project, all the way up until you finish your project.
您还应该在整个项目中使用行动项,一直使用到项目完成。
How to Use Them
如何使用它们
Okay, so you know that using action items will help you finish your project, but how can you use them?
好的,所以你知道使用行动项目将帮助你完成你的项目,但是你如何使用它们呢?
To help get your laptop/tablet combo project headed in the right direction, your first action item can very well be this:
为了帮助你的笔记本/平板电脑组合项目朝着正确的方向前进,你的第一个行动项目可以是:
Assign roles for new project. 为新项目分配角色
You can send out an email telling your team that at the next meeting, you will be working on the action item of assigning roles. To help everyone get on the same page, your email can even list the action items that need to be done next. This way, when your team gets together to discuss the project, everyone will know what needs to be done, and they will be ready to help you figure out who is going to be doing what.
你可以发送一封电子邮件告诉你的团队,在下一次会议上,你将着手分配角色的行动项目。为了帮助每个人达成共识,你的邮件甚至可以列出下一步需要做的事情。这样,当你的团队聚在一起讨论项目时,每个人都会知道需要做什么,他们也会准备好帮助你找出谁将要做什么。
After the roles have been assigned, you can then start working on the other action items, such as these:
在角色分配完成后,你可以开始处理其他的动作项,比如:
Design 4 possible styles for review, due by next week. 设计4种可能的款式供评审,下周交
Find 4 possible wholesalers that make quality screens, due by next week. 找到4个可能的批发商,生产高质量的屏幕,到下周为止
Write 4 different possible specs for the new laptop/tablet, due by next week. 为下周到期的新笔记本/平板电脑写下4种不同的可能规格
These action items will get you to the next step of your project where you start to assemble the first prototype of your product.
这些行动项目将帮助您进入项目的下一步,您将开始组装产品的第一个原型。
The best way to use action items is by continuing to create new ones as you finish your previous action items. This will get you closer to finishing your project one step at a time.
使用行动项的最佳方式是在完成之前的行动项的同时继续创建新的行动项。这将使你更接近完成您的项目一步一步的时间。
Include due dates with your action items so you know when you need to finish each step and action item. Also, make sure that your action items have an action associated with what you are supposed to do. For example, you wrote ‘‘Design 4 possible styles for review, due by next week’’ instead of just ‘‘Possible styles’’. By including an action, you are clearly stating what you need to do.
在你的行动项目中包括截止日期,这样你就知道什么时候你需要完成每个步骤和行动项目。此外,确保你的行动项目有一个与你应该做的事情相关联的行动。例如,你写的是"设计4种可能的样式供评审,下周交"而不是"可能的样式"。通过包含一个动作,你就清楚地说明了你需要做什么。
活动项可以帮助我们更好的管理项目,我们小组的项目也可以通过列出活动项的方式进行管理。
the actual value that is passed into the method by a caller
调用方传入方法的实际值
actual parameter 实际参数 — the actual value that is passed into the method by a caller. ー调用方传入方法的实际值
For example, the 例如:200 used when 用于processDeposit is called is an actual parameter. 是一个实际的参数
actual parameters are often called 实际参数通常被称为arguments 争论
When a method is called, the formal parameter is temporarily “bound” to the actual parameter. The method uses the formal parameter to stand for the actual value that the caller wants to be used.
调用方法时,形式参数临时"绑定"到实际参数。该方法使用形式参数表示调用方希望使用的实际值。
For example, here the processDeposit method uses the formal parameter amount to stand for the actual value used in the procedure call:
例如,这里 processDeposit 方法使用形式参数 amount 来表示过程调用中使用的实际值:
balance = balance + amount ;
Note: formal parameters are bound to an actual value only as long as their method is active. When a method returns to its caller, the formal parameters no longer contain any values. They cannot be used to store the state of an object.
注意: 形式参数只有在其方法处于活动状态时才与实际值绑定。当方法返回给调用方时,形式参数不再包含任何值。它们不能用于存储对象的状态。
实际参数和形式参数是在编程时需要注意的概念,初学者可能会搞不清楚,可以理解为实际参数是真实存在的,形式参数只有在调用时才发挥传递参数的作用。
Application software, or app for short, is software that performs specific tasks for an end-user.
应用软件,简称 app,是为最终用户执行特定任务的软件。
Effectively, if the user is interacting directly with a piece of software it is application software. For example, Microsoft Word or Excel are application software, as are common web browsers such as Firefox or Google Chrome.
实际上,如果用户直接与一个软件进行交互,那么它就是应用软件。例如,Microsoft Word 或 Excel 是应用软件,常见的网络浏览器如 Firefox 或 Google Chrome 也是应用软件。
It also includes the category of mobile apps, including communication apps such as WhatsApp or games such as Candy Crush Saga. There are also app versions of common services such as those providing weather or transport information or apps for customers to interact with companies.
它还包括一类移动应用,包括诸如 WhatsApp 之类的通讯应用,或者诸如糖果大爆险之类的游戏。还有应用程序版本的公共服务,如那些提供天气或交通信息或应用程序的客户与公司互动。
Application software is distinct from system software, which refers to the software that actually keeps the systems running such as the operating system, computational science software, game engines, industrial automation, and software as a service applications.
应用软件不同于系统软件,系统软件指的是实际上保持系统运行的软件,如操作系统、计算科学软件、游戏引擎、工业自动化和软件即服务应用程序。
Instead of interacting with the user, the system software interacts with other software or hardware.
系统软件不是与用户交互,而是与其他软件或硬件交互。
应用软件有区别于系统软件,虽然我们是要开发一个实验室管理系统,但是我们的系统应该基于一些操作系统的,如windows系统或者安卓系统,ios系统,我们的系统最终呈现出来的结果应该是一个应用软件,系统软件值得实际上是保持系统运行的软件,我们是在系统软件的基础上进行开发
Algorithm analysis is a quantitative analysis of how much computing time and storage space an algorithm needs. Algorithm is the step of solving a problem. It can be defined as any special method to solve a certain problem. In computer science, the algorithm should be described by computer algorithm language, and the algorithm represents an accurate and effective method to solve a class of problems by computer.
算法分析是对一个算法需要多少计算时间和存储空间作定量的分析。 算法(Algorithm)是解题的步骤,可以把算法定义成解一确定类问题的任意一种特殊的方法。在计算机科学中,算法要用计算机算法语言描述,算法代表用计算机解一类问题的精确、有效的方法。
Usually, the efficiency or running time of an algorithm is stated as a function relating the input length to the number of steps (time complexity) or storage locations (space complexity). Algorithm analysis is an important part of a broader computational complexity theory, which provides theoretical estimates for the resources needed by any algorithm which solves a given computational problem. These estimates provide an insight into reasonable directions of search for efficient algorithms. In theoretical analysis of algorithms it is common to estimate their complexity in the asymptotic sense, i.e., to estimate the complexity function for arbitrarily large input. Big O notation, Big-omega notation and Big-theta notation are used to this end.
通常,一个算法的效率或运行时间表示为一个函数,它将输入长度与步数(时间复杂度)或存储位置(空间复杂度)联系起来。算法分析是更广泛的计算复杂性理论分析的一个重要组成部分,它为任何解决给定计算问题的算法所需的资源提供理论估计。这些估计为寻找高效算法提供了合理的方向。在算法的理论分析中,通常是在渐近意义上估计它们的复杂度,即对任意大的输入估计复杂度函数。大 o 符号、大 -omega 符号和大 -theta 符号被用于此目的。
Rule of thumb: 经验法则: Simple programs can be analyzed by counting the nested loops of the program. A single loop over n items yields f( n ) = n. A loop within a loop yields f( n ) = n 简单的程序可以通过计算程序的嵌套循环来进行分析。在 n 个项上的单个循环产生 f (n) = n。循环中的循环产生 f (n) = n2. A loop within a loop within a loop yields f( n ) = n . 循环中的循环产生 f (n) = n3.
Rule of thumb: 经验法则:Given a series of for loops that are sequential, the slowest of them determines the asymptotic behavior of the program. Two nested loops followed by a single loop is asymptotically the same as the nested loops alone, because the nested loops dominate the simple loop. 给定一系列顺序的 for 循环,其中最慢的一个决定了程序的渐近行为。两个嵌套循环后跟一个单循环是渐近相同的嵌套循环单,因为嵌套循环主导的简单循环
算法是一组有穷的规则,它们规定了解决某一特定类型问题的一系列运算,是对解题方案内的准确与完整地描述。制定一个算法,一般要经过设计、确认、分析、编码、测试、调试、计时等阶段。
系统功能的实现本质上其实就是各种算法的实现,在需求分析阶段不需要过于考虑算法的实现,而应该确认好需求后在选择相适应的算法去实现我们的系统
A base address is a unique location in primary storage (or main memory) that serves as a reference point for other memory locations called absolute addresses.
基地址是主存储器(或主存储器)中唯一的位置,作为其他内存位置(称为绝对地址)的参考点。
In order to obtain an absolute address, a specific displacement (or offset) value is added to the base address. In primary storage, all addresses literally comprise fixed-length sequences of bits that stand for positive whole numbers usually expressed in hexadecimal form. For example, a base address might indicate the beginning of a program loaded into primary storage. The absolute address of each individual program instruction could be specified by adding a displacement to the base address.
为了获得一个绝对地址,一个特定的位移(或偏移量)值被加到基地址。在主存储器中,所有地址实际上都包含固定长度的位序列,这些位代表通常以十六进制形式表示的正整数。例如,基址可能表示加载到主存储器的程序的开始。每条单独程序指令的绝对地址可以通过在基地址上添加一个位移来指定。
Reverse Engineering (also known as reverse technology) is a process of reappearance of product design technology, that is, reverse analysis and Research on a target product, so as to deduce and obtain the design elements of the product, such as processing flow, organizational structure, functional characteristics and technical specifications, so as to produce similar but not identical products. Reverse engineering comes from hardware analysis in commercial and military fields. Its main purpose is to deduce the design principle of the product directly from the analysis of the finished product when the necessary production information cannot be obtained easily.
逆向工程(又称逆向技术),是一种产品设计技术再现过程,即对一项目标产品进行逆向分析及研究,从而演绎并得出该产品的处理流程、组织结构、功能特性及技术规格等设计要素,以制作出功能相近,但又不完全一样的产品。逆向工程源于商业及军事领域中的硬件分析。其主要目的是在不能轻易获得必要的生产信息的情况下,直接从成品分析,推导出产品的设计原理。
The reasons for reverse engineering are as follows:
Interface design. Because of interoperability, reverse engineering is used to find out the cooperation protocol between systems.
● military or commercial secrets. Steal the latest research or product prototype of an enemy or competitor.
● improve documentation. When the original documents are inadequate, and when the system is updated and the original designer is not present, reverse engineering is used to obtain the required data to supplement or understand the latest state of the system.
● software upgrade or update. For functional, compliance, security requirements changes, reverse engineering is used to understand existing or legacy software systems to assess the work required to update or migrate systems.
● manufacturing unlicensed / unauthorized copies.
● academic / learning purposes.
● remove replication protection and disguised login rights.
Document loss: when reverse engineering is adopted, the document of a special equipment has been lost (or not at all), and the person in charge of the project cannot be found. The complete system often needs to be redesigned based on the old system, which means that the only way to integrate the original functions for the project is to use the reverse engineering method to analyze the existing fragments for redesign.
Product analysis: used to investigate the operation mode, component composition, budget estimation and identification of potential infringement.
Make game plug-in: understand the game operation mechanism through reverse engineering, then bypass the protection mechanism, and realize the plug-in function by modifying the memory value, modifying the code in memory, and calling internal functions.
需要逆向工程的原因如下:
●接口设计。由于互操作性,逆向工程被用来找出系统之间的协作协议。
●军事或商业机密。窃取敌人或竞争对手的最新研究或产品原型。
●改善文档。当原有的文档有不充分处,又当系统被更新而原设计人员不在时,逆向工程被用来获取所需数据,以补充说明或了解系统的最新状态。
●软件升级或更新。出于功能、合规、安全等需求更改,逆向工程被用来了解现有或遗留软件系统,以评估更新或移植系统所需的工作。
●制造没有许可/未授权的副本。
●学术/学习目的。
●去除复制保护和伪装的登录权限。
●文件丢失:采取逆向工程的情况往往是在某一个特殊设备的文件已经丢失了(或者根本就没有),同时又找不到工程的负责人。完整的系统时常需要基于陈旧的系统上进行再设计,这就意味着想要集成原有的功能进行项目的唯一方法,便是采用逆向工程的方法,分析已有的碎片进行再设计。
●产品分析:用于调查产品的运作方式,部件构成,估计预算,识别潜在的侵权行为。
●制作游戏外挂:通过逆向工程了解游戏运行机制,进而绕过保护机制并通过修改内存数值、修改内存中的代码、调用内部函数等方式来实现外挂功能。
Reverse engineering is widely used in new product development, product modification design, product imitation, quality analysis and testing
Shorten the design and development cycle of products and speed up the update of products;
Reduce the cost and risk of developing new products;
Speed up the design of product modeling and serialization;
Suitable for single piece, small batch parts manufacturing, especially mold manufacturing, can be divided into direct molding and indirect molding. Direct molding method: the rapid direct molding method based on RP technology is to directly manufacture and shape the CAD results of mold by RP system. This method does not need RP system to make sample parts, and does not rely on traditional mold manufacturing process. It is particularly fast for metal mold manufacturing, and it is a mold making method with great development prospect; indirect mold making method: indirect molding method is to use RP technology to manufacture product parts prototype, and the original mold is used as mother mold, mold core or mold making tool (grinding mold), and then combined with traditional mold making process Make the required mold.
逆向工程被广泛地应用到新产品开发和产品改型设计、产品仿制、质量分析检测等领域,它的作用是:
缩短产品的设计、开发周期,加快产品的更新换代速度;
降低企业开发新产品的成本与风险;
加快产品的造型和系列化的设计;
适合单件、小批量的零件制造,特别是模具的制造,可分为直接制模与间接制模法。直接制模法:基于RP技术的快速直接制模法是将模具CAD的结果由RP系统直接制造成型。该法既不需用RP系统制作样件,也不依赖传统的模具制造工艺,对金属模具制造而言尤为快捷,是一种极具开发前景的制模方法;间接制模法:间接制模法是利用RP技术制造产品零件原型,以原型作为母模、模芯或制模工具(研磨模),再与传统的制模工艺相结合,制造出所需模具。
The bathtub curve is a type of model demonstrating the likely failure rates of technologies and products.
浴缸曲线是一种模型,用来说明技术和产品的可能失败率。
One function of the bathtub curve is to show the likelihood of initial failure with products. Companies try to eliminate the first infant mortality phase by refining products and engineering to eliminate “dead on arrival” products. There is a sense that products that fail quickly will turn away customers. Companies might use specific tasks like a highly accelerated life test (HALT) or a highly accelerated stress test (HAST) to try to promote the engineering of more durable and long-lasting products. Technology experts may talk about eliminating the causes of “infant mortality” failures. All of this is part of specific product development and quality control in the enterprise world.
浴缸曲线的一个作用是显示产品初始失效的可能性。企业试图通过改进产品和工程,消除"一到就死"的产品,从而消除婴儿死亡的第一阶段。人们有一种感觉,那些很快失败的产品会把消费者拒之门外。公司可能会使用诸如高加速寿命测试(HALT)或高加速压力测试(HAST)这样的特定任务来试图促进更耐用和持久产品的工程设计。技术专家可能会谈论消除"婴儿死亡率"失败的原因。所有这些都是企业界特定产品开发和质量控制的一部分。
我们在做需求分析的时候也可以用到浴缸曲线来显示产品初始失效的可能性。
In the environment in which software is created, the term “availability” refers to a method that places the user, rather than the system, at the center of the process. This method is called user centered design. It takes the concerns and opinions of users into account from the beginning of the design process, and puts forward that the needs of users should be put in the first place in any design decision.
在创建软件的环境中,术语"可用性"表示一种方法,它将用户而不是系统摆在过程的中心。这一方法称作以用户为中心的设计,它从设计过程的一开始就将用户关心的问题和意见考虑在内,并提出在任何设计决策中用户的需要都应摆在首位。
在工作中体现可用性
在创建软件的环境中,术语"可用性"表示一种方法,它将用户而不是系统摆在过程的中心。这一方法称作以用户为中心的设计,它从设计过程的一开始就将用户关心的问题和意见考虑在内,并提出在任何设计决策中用户的需要都应摆在首位。
这种方法最显著的特点就是可用性测试。在测试中,用户使用产品的界面进行工作,通过界面进行交互,就他们的观点和关心的问题与设计人员和开发人员进行交流。
本文讨论了可用性的概念,并讨论了为什么可用性在所有软件设计项目中都是一个重要部分。本文的第一部分定义了在软件开发环境中可用性意味着什么,以及它与衡量产品价值的其它方面间的关联。第二部分回答了一些常见的问题,包括:为什么可用性很重要,以及如何在开发过程中体现以用户为中心的设计理念等。本文在结尾处列出了一些书籍、论文和组织机构名称,帮助您加深对可用性的了解,并在项目中应用可用性。
本文中讨论的大部分概念在零售和内部软件开发中均有所应用。在阅读本文时,请注意"用户"和"产品"等词语,并思考如何将其应用到您的项目和最终用户中。
可用性定义
易于使用
可用性是衡量使用一种产品来执行指定任务的难易程度的尺度,它与实用性和受欢迎度等相关概念是有差异的。
可用性与实用性
决定产品可接受性的核心属性是其有用性,它用于评价实际使用产品时,是否能达到设计人员期望产品实现的目标。有用性的概念可以进一步划分为实用性和可用性。虽然这些术语间有联系,但它们却不能相互替代。
实用性指产品执行任务的能力。根据设计,产品执行的任务越多,其实用性就越高。
让我们以二十世纪八十年代末问世的典型 Microsoft® MS-DOS® 字处理程序为例。此类程序提供了多种强大的文本编辑和处理功能,但需要用户学习和记忆几十个令人费解的按键后才能执行这些功能。可以说此类应用程序具有很高的实用性(它们为用户提供了必要的功能),但其可用性却较差(用户必须花费大量的时间和精力来学习和使用它们)。与之形成对比的是,一个设计合理的简单的应用程序(如计算器)使用起来很容易,但其实用性却有欠缺。
这两种性质都是一种产品被市场接受所必需的,而且它们都是总的有用性概念的一部分。显然,若程序很好用但没有什么有价值的功能,那么没有人会使用它;如果程序的功能强大但却很难使用,那么用户也很可能会拒绝这个程序而转向其它的替代品。
可用性测试帮助您判断用户使用产品执行特殊任务的难易程度。但是,它并不能直接帮助您判断产品自身是否有价值、是否实用(在可用性测试中,用户可能会主动提出一些关于实用性的意见,但任何意见都应通过其它更可靠的研究方法予以验证)。
喜欢它与使用它
受欢迎度往往表示产品中可取的特性。如果人们喜欢某产品,就更有可能使用它,并将它推荐给其他人。但是,与实用性一样,您一定要小心不要将受欢迎度和可用性混淆。
人们喜欢某产品的原因往往与实用性和可用性无关。他们可能被产品的样式和引人注目的外观吸引,或被心目中所赐予的该产品的地位吸引。人们倾向于喜欢很好用的产品,但这并不是说人们普遍喜爱的产品就是可用的。
可用性是指人们是否可以使用该产品来执行他们需要执行的任务。可用性测试主要用于评价性能而不是评价喜爱程度,但标准化的调查问卷也可以用来衡量人们对产品的喜爱程度。
发现、学习与有效性
可用性包含很多方面,但通常这一术语特指发现、学习和有效性这三种属性。
发现表示针对某种特定的需要去寻找并找到产品的某一功能。可用性测试可用于确定用户找到某一功能所用的时间,以及在整个过程中用户犯了多少错误(关于定位的错误选择)。
学习表示用户弄清楚如何运用所发现的功能来完成现有任务的过程。可用性测试可以确定这个过程的长短,以及在学习该功能期间用户犯了多少错误。
有效性表示用户"掌握"了某项功能,不再需要进一步学习即可使用。可用性测试可以确定有经验的用户使用该功能时执行必要步骤所需的时间。
可用性的这三个基本方面在很大程度上受到当前任务性质和用户执行任务的频率的影响。有些功能的使用频率很低或者使用起来十分复杂,导致用户基本上每次使用时都要重新学习;对于这些功能,Microsoft 通常开发了使用向导,在整个使用过程中对用户予以指导。
光喊口号是不够的
软件设计人员有时以为简单的口号,如"使产品更可用",就可以解决可用性问题。虽然对可用性的积极态度是重要的,但是只有在具体的产品创建环境中,通过对普通用户进行恰当的可用性测试,才能为设计人员提供所需的信息,使产品可以满足用户的需要。"使产品更可用"应当成为每个软件设计人员的座右铭,但是这句话只对那些了解"可用性"含义的设计人员才有意义。而对普通用户进行测试就是可以找到的最可靠的途径。
常见问题
为什么要强调可用性问题呢?
如果您还没有在产品设计过程中将可用性因素考虑在内,您可能会问:可用性为什么是必要的,或可用性为什么是可取的?毕竟,不进行任何可用性工作,也可能发售一个可以工作的、没有错误的产品。但是,通过引入以用户为中心的设计理念可以使产品在很多方面得以很大改进。
减少用户拨打技术支持电话的次数是执行可用性测试的最佳理由。较差的可用性是用户拨打软件技术支持热线的主因,而每个软件公司主管以及信息服务经理都知道产品支持的成本是多么昂贵。此外,用户不得不寻求技术支持增加了用户对产品的潜在不满情绪。如果用户发现贵公司的产品使用起来十分容易,那么他们就不必频繁地打电话寻求技术支持了。
对于内部使用的软件,之所以将可用性作为开发过程中的一个重要部分,其原因还在于它减少了培训费用。对用户而言,可用性强的软件学习起来比可用性不受重视的产品学习起来要容易得多。用户能够更快地了解产品的各项功能,并能长久地掌握它,这直接减少了培训费用和时间。
可用性测试有助于促进用户对产品的接受程度。有很多因素决定了用户对产品的接受程度,这些因素包括可用性、实用性和受欢迎度。对于零售产品,用户的接受程度往往直接影响对产品的重复购买或对产品的忠诚度,这说明用户可能将产品推荐给其他人。对于内部应用程序,用户的接受程度决定用户是否愿意使用该软件执行任务,而这些软件就是针对这些任务设计的,这有助于提高生产效率。提高可用性是提高用户对产品的接受程度的一个因素。
可用性可将您的产品与您的竞争对手的产品区分开来。如果两个产品在实用性方面从本质上讲是一样的,那么人们很可能认为可用性更好的产品高出一筹。此外,由于 Microsoft® Windows® 的外观和感受以及随附的编程准则划定了基本用户界面的使用区域的标准,因此很多执行相似功能的程序其外观与操作在相当大的程度上是相似的。这些相似性表明,即使可用性上的细微差异也会对用户的喜好产生重大的影响。
最后请记住,每个产品最终都要进行可用性测试。用户每次使用您的产品时,都是在对它进行可用性测试,而他们对可用性优劣的意见将会影响他们是否继续使用该产品。将产品推向市场之前,对产品进行测试,可以有助于确保用户对产品的满意程度。
它的花费是多少?
软件设计人员和项目经理往往担心,如果采用以用户为中心的设计过程并执行适当的可用性测试,恐怕要占用大量的时间并花费大量的金钱。事实上,花费在关注用户方面的时间和金钱通常是相当少的,而且与不这样做而导致的花费相比,这点花费也是微不足道的。
例如,设想一下在开发周期的后期而不是在前期(产品仍处在开发阶段时)对设计进行修正您要花费多少时间和金钱吧!如果您一直等到 Beta 测试时期才使用户接触到产品以便进行可用性测试,就会发现自己不得不将花费了大量时间开发的程序的各部分分拆重做。而若等到产品真正发布时,如果要根据负面反馈进行修改或支持较差的设计,因为产品支持的庞大开销或用户对产品的接受程度较差等原因,很可能要支付高昂的费用。
合理的可用性研究通常只需要两周或更短的时间,并可以显著减少开发周期后期进行修改所需的时间和金钱。进行测试所需的花费将根据您的产品的性质以及所测试的界面部分的不同而有所不同。
可以认为可用性测试与代码测试是类似的。成功的项目经理在计划开发项目时总是会考虑到代码测试。他们并不认为代码测试是项目时间表或预算外的额外部分,而是将代码测试作为开发过程的一部分而计入成本。因为若不进行代码测试,那么花费反而会高得多。对于可用性测试,情况也是如此。
怎样获得可用性?
在理解可用性的重要性基础上,软件设计人员有时试图"获得"一些可用性,就好象可用性是一种成分,他们可以简单地把它添加到产品中,这样产品就更可用了。然而,可用性应当是设计过程本身的一部分,不是您可以在设计过程的随便某一地方添加的"东西"。可用性专家提到"用户关注的"与"以用户为中心的设计"的原因是:可用性取决于将用户的需要一直作为设计过程的中心。以用户为中心的设计根据需要的不同,包含的内容不单单是在界面中按照一组规则,对按钮和菜单布置进行管理。可用性测试是对设计工作进行检查的良机,而不是在产品中"添加"可用性的一种方法。
一旦您决定我们以用户为中心的设计原理运用到您的开发过程中,就需要决定是自己雇佣可用性专业人员还是将可用性测试外包给供应商。
可用性专业人员协会 (UPA) 有一份供应商指南,有助于找到为您执行测试的可用性顾问。
有些咨询部门还可以帮助您创建您自己的可用性实验室或开发内部的可用性程序,在您的设计过程中引入可用性理念。
自己雇佣可用性专业人员,那么 Human Factors and Ergonomics Society 有职业介绍服务,使您可以找到潜在的雇员。很多可用性专业人员还属于 ACM Special Interest Group on Computer-Human Interaction (SIGCHI) 和 UPA,您也可以在他们的出版物和会刊上刊登招聘广告。
Algorithm refers to the definite and limited steps taken to solve a specific problem. The computer programming language used to express algorithms is called algorithmic language. Algorithmic language is a description tool of algorithm and a general language between machine language and mathematical language
算法是指为解决某个特定问题而采取的确定且有限的步骤 [1] 。用来表达算法的计算机程序设计语言称为算法语言(Algorithmic language)。算法语言是算法的一种描述工具,是介于机器语言和数学语言之间的一种通用语言
Computer language is divided into machine language, assembly language and high-level language. High level language is a kind of artificial design language, because it describes the specific algorithm, so it is also called algorithm language.
Computer has been widely used in various fields of social life, and has become a popular modern tool. People will need to do the work of the computer into a certain form of instructions, and they are stored in the internal memory of the computer, when people give the command, it will automatically operate according to the order of instructions. This set of instructions that can be executed continuously is called “program”. It can be said that program is the language of “dialogue” between human and machine, that is, we often say “programming language”.
At present, there are hundreds of programming languages used in the society, such as C, visual basic, C + + and Java, which are called “advanced languages” of computers. These languages are close to people’s habits of natural language and mathematical language as a form of expression, making it very convenient for people to learn and operate.
Common algorithm languages include basic, FORTRAN, COBOL, Pascal, C, C + + and Java.
计算机语言分机器语言、汇编语言和高级语言。其中高级语言是一类人工设计的语言,因为它对具体的算法进行描述,所以又称为算法语言。
计算机现已广泛应用于社会生活的各个领域,成为大众化的现代工具。人们将需要计算机做的工作写成一定形式的指令,并把它们存储在计算机内部的存储器中,当人们给出命令之后,它就按指令顺序自动进行操作。人们把这种可以连续执行的一条条指令的集合称为"程序"。可以说,程序就是人与机器"对话"的语言,也就是我们常说的"程序设计语言"。
目前,在社会上使用的程序设计语言有上百种,如C、Visual Basic、C++和Java等被称为计算机的"高级语言"。这些语言都是用接近人们习惯的自然语言和数学语言作为表达形式,使人们学习和操作起来感到十分方便 [1] 。
常见算法语言有BASIC、FORTRAN、COBOL、PASCAL、C、C++和JAVA等。
One of the prerequisites for the development of a software system is that we have a definition and a clear understanding of the contents of the application domain concerned. This is the part of an organization for which we are to develop application software. This means that the application domain is our starting point and the context for our software development.
开发软件系统的先决条件之一是我们对有关应用领域的内容有一个清晰的定义和理解。这是我们为其开发应用软件的组织的一部分。这意味着应用程序领域是我们软件开发的起点和上下文。
An application domain is the segment of reality for which a software system is developed. It is the background or starting point for the actual-state analysis and the creation of a domain model.
应用领域是软件系统开发的现实环节。它是实际状态分析和领域模型创建的背景或出发点。
An application domain can be an organization, a department within an organization, or a single workplace.
应用程序域可以是组织、组织中的部门或单个工作场所。
The concept of an application domain is at least as wide, so that the domain concepts and relations relevant for the construction of models can be well understood during the analysis of the actual state of the domain. On the other hand, its extent should always be limited, that is, never be too complex.
应用程序领域的概念至少是同样广泛的,因此在分析领域的实际状态时,可以很好地理解与模型构造相关的领域概念和关系。另一方面,它的范围应该总是有限的,也就是说,永远不要太复杂。
An application domain normally includes a domain-specific language. This means that people in this domain use specific terms and concepts and think about their domain in a specific way.
一个应用程序域通常包括一个领域特定语言。这意味着这个领域的人使用特定的术语和概念,并以特定的方式思考他们的领域。
The application domain is very important, because it is critical for our application-oriented way of developing software. The developers analyze and describe the actual tasks and situations (see Section 6.41) that characterize the application domain in the domain-specific language. This corresponds to an actual-state analysis, where the typical processes and the objects used in these processes are represented in their domain-specific use contexts, for example, as scenarios or glossary entries (see Section 5.3.11). It is similar to the business model in UP. At the same time, the application domain is the basis for the construction of a domain model. Together with the analysis and description of the actual state within the application domain, we are gradually building the domain model.
应用领域非常重要,因为它对于我们面向应用的软件开发方式至关重要。开发人员分析和描述实际的任务和情况 ,这些任务和情况描述了领域特定语言应用程序中的应用域。这与实际状态分析相对应,在这种分析中,这些流程中使用的典型流程和对象在其特定于领域的使用上下文中表示,例如,作为场景或术语表条目。它类似于 UP 的商业模式。同时,应用领域是构建领域模型的基础。结合对应用领域内实际状态的分析和描述,我们正在逐步构建领域模型。
Building a domain model
构建领域模型
This model represents the segment of the actual application domain to be supported by the software system under development. Obviously, our domain model is similar to the domain model in UP. Later in this chapter, we will explore the question whether or not the UP domain model can meet all our requirements, that is, easy to understand and easy to construct, as one model.
此模型表示开发中的软件系统所支持的实际应用程序域的部分。显然,我们的领域模型类似于 UP 中的领域模型。在本章的后面,我们将探索 UP 领域模型是否能够满足我们的所有需求,即作为一个模型易于理解和易于构造的问题。
This interest of developers in an application domain is not limited to the segments that will be mapped in the domain model; they will also deal with segments required to understand the current work situation within the actual-state analysis. It is at once a risk and an art to find the right limits for the actual-state analysis, and not to let it get out of hand both in terms of time and content. Experiences from traditional data-modeling projects have shown that it is simply not possible to achieve a complete analysis of the entire application domain. The first notion of the future application system will help developers find the right point to stop analyzing. This means that the developers have to gain quick insight about the points of the application domain where software support could be useful and feasible.
开发人员对应用程序领域的兴趣并不局限于将映射到领域模型中的片段; 他们还将处理理解实际状态分析中当前工作情况所需的片段。为实际状态分析找到正确的界限,并且不让它在时间和内容上失控,这既是一种风险,也是一种艺术。传统数据建模项目的经验表明,完全分析整个应用程序领域是不可能的。未来应用程序系统的第一个概念将帮助开发人员找到停止分析的正确点。这意味着开发人员必须快速了解应用程序领域中哪些地方的软件支持可能是有用的和可行的。
应用程序域 (application domain) (App Domain) 一种边界,它由公共语言运行库围绕同一应用程序范围内创建的对象建立(即,从应用程序入口点开始,沿着对象激活的序列的任何位置)。应用程序域有助于将在一个应用程序中创建的对象与在其他应用程序中创建的对象隔离,以使运行时行为可以预知。在一个单独的进程中可以存在多个应用程序域。
Software architecture is a series of related abstract patterns, which are used to guide the design of various aspects of large-scale software system.
软件架构(software architecture),是一系列相关的抽象模式,用于指导大型软件系统各个方面的设计。
There is no doubt that the world is becoming increasingly dependent on software. Software is an essential element of the ubiquitous cell phone, as well as complex air traffic control systems. In fact, many of the innovations that we now take for granted – including organizations such as eBay or Amazon – simply wouldn’t exist if it weren’t for software. Even traditional organizations, such as those found in the finance, retail, and public sectors, depend heavily on software. In this day and age, it’s difficult to find an organization that isn’t, in some way, in the software business.
毫无疑问,世界正变得越来越依赖软件。软件是无处不在的手机以及复杂的空中交通管制系统的基本元素。事实上,许多我们现在认为理所当然的创新---- 包括像 eBay 或亚马逊这样的组织---- 如果不是因为软件,根本不会存在。即使是传统的组织,比如那些在金融、零售和公共部门的组织,也严重依赖软件。在当今这个时代,很难找到一个在某种程度上不属于软件行业的组织。
In order for such innovations and organizations to survive, the software they depend on must provide the required capability, be of sufficient quality, be available when promised, and be delivered at an acceptable price.
为了使这些创新和组织能够生存下去,他们所依赖的软件必须具备必要的能力,必须具备足够的质量,必须在承诺时提供,并且以可接受的价格交付。
All these characteristics are influenced by the architecture of the software, the subject of this article. My focus here is on “software-intensive systems,” which the IEEE defines as follows:
所有这些特征都受到本文主题------软件体系结构的影响。我在这里的重点是"软件密集型系统" ,IEEE 对它的定义如下:
A software-intensive system is any system where software contributes essential influences to the design, construction, deployment, and evolution of the system as a whole. [from IEEE 1471. See the “Architecture defined” section below.]
软件密集型系统是任何系统,其中软件对整个系统的设计、构建、部署和演进有重要影响。[摘自 IEEE 1471。参见下面的"体系结构定义"部分。]
In this article, the term “architecture,” when unqualified, is synonymous with the term “software architecture.” Although this article focuses on software-intensive systems, it is important to remember that a software-intensive system still needs hardware in order to execute and that certain qualities, such as reliability or performance, are achieved through a combination of software and hardware. The hardware aspect of the total solution cannot therefore be ignored. This is discussed in more detail later in this article.
在本文中,术语"架构"(当不合格时)与术语"软件架构"是同义词虽然本文侧重于软件密集型系统,但是重要的是要记住,软件密集型系统仍然需要硬件来执行,并且某些特性,如可靠性或性能,是通过软件和硬件的组合来实现的。因此,不能忽略整个解决方案的硬件方面。本文后面将更详细地讨论这个问题。
Architecture defined
体系结构定义
There is no shortage of definitions when it comes to “architecture.” There are even Websites that maintain collections of definitions.1 The definition used in this article is that taken from IEEE Std 1472000, the IEEE Recommended Practice for Architectural Description of Software-Intensive Systems, referred to as IEEE 1471.2 This definition follows, with key characteristics bolded.
当涉及到"体系结构"时,并不缺少定义本文中使用的定义来自 IEEE Std 1472000,IEEE 软件密集型系统架构描述的推荐实践,简称 IEEE 1471.2。
Architecture is the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution. [IEEE 1471]
体系结构是一个系统的基本组织,体现在其组成部分、它们之间的关系、与环境的关系以及指导其设计和发展的原则上。1471]
This standard also defines the following terms related to this definition:
本标准还定义了与本定义相关的以下术语:
A system is a collection of components organized to accomplish a specific function or set of functions. The term system encompasses individual applications, systems in the traditional sense, subsystems, systems of systems, product lines, product families, whole enterprises, and other aggregations of interest. A system exists to fulfill one or more missions in its environment. [IEEE 1471]
系统是组织起来完成特定功能或一组功能的组件的集合。术语系统包括单个应用程序、传统意义上的系统、子系统、系统的系统、产品线、产品系列、整个企业以及其他感兴趣的集合。一个系统的存在是为了在它的环境中完成一个或多个任务。1471]
The environment, or context, determines the setting and circumstances of developmental, operational, political, and other influences upon that system. [IEEE 1471]
环境,或者说环境,决定了发展的、可操作的、政治的以及其他影响该系统的因素的背景和环境。1471]
A mission is a use or operation for which a system is intended by one or more stakeholders to meet some set of objectives. [IEEE 1471]
任务是一个或多个利益相关者为了实现某些目标而设计的系统的使用或操作。1471]
A stakeholder is an individual, team, or organization (or classes thereof) with interests in, or concerns relative to, a system. [IEEE 1471]
涉众是个人、团队或组织(或其类别) ,他们对系统感兴趣,或者与系统有关。1471]
As we can see, the term “component” is used throughout these definitions. However, most definitions of architecture do not define the term “component,” and IEEE 1471 is no exception, as it leaves it deliberately vague to cover the many interpretations in the industry. A component may be logical or physical, technology-independent or technology-specific, large-grained or small-grained. For the purposes of this article, I use the definition of component from the UML 2.0 specification; and I use the term fairly loosely in order to encompass the variety of architectural elements that we may encounter, including objects, technology components (such as an Enterprise JavaBean), services, program modules, legacy systems, packaged applications, and so on. Here is the UML 2.0 definition for “component”:
正如我们所看到的,术语"组件"贯穿于这些定义之中。然而,架构的大多数定义并没有定义术语"组件" ,IEEE 1471也不例外,因为它故意使它含糊不清,以涵盖行业中的许多解释。组件可以是逻辑的或物理的、技术独立的或特定于技术的、大粒度的或小粒度的。出于本文的目的,我使用了 UML 2.0规范中的组件定义; 我相当松散地使用这个术语是为了包含我们可能遇到的各种架构元素,包括对象、技术组件(如企业 JavaBean)、服务、程序模块、遗留系统、打包应用程序等等。
软件架构所指的就是说相应的系列性的抽象模式,可以为设计大型软件系统的各个方面提供相应的指导。从本质上来看,软件架构是属于一种系统草图。在软件架构所描述的对象就是直接的进行系统抽象组件构成。连接系统的各个组件之间就是做到把组件之间所存在的通讯比较明确与相对细致的实施描述。处于相应的系统实现环节,那么就会使得细化这些抽象组件成为现实的组件,比如可以是具体的某个类或者是对象。从面向对象领域进行分析,那么各个组件之前实施的连接实现往往是接口。
软件架构为软件系统提供了一个结构、行为和属性的高级抽象,由构件的描述、构件的相互作用、指导构件集成的模式以及这些模式的约束组成。软件架构不仅显示了软件需求和软件结构之间的对应关系,而且指定了整个软件系统的组织和拓扑结构,提供了一些设计决策的基本原理。
能够将软件架构划分成为三种类型。
逻辑架构
软件系统系统当中的各个元件之间所存在的关系,比如外部系统接口、用户界面、商业逻辑元件、数据库等。
物理架构
究竟是怎样做到在硬件当中放置软件元件。例如处于上海与北京进行分布的分布式系统的物理架构,这也就是说全部的元件都是属于物理设备,主要的有主机、整合服务器、应用服务器、代理服务器、存储服务器、报表服务器、Web服务器、网络分流器等。
系统架构
相应的系统存在着性能、强壮性、可扩展性、灵活性、可靠性等这些非功能性特征。设计系统的架构比要让系统架构设计人员存在着过硬的软件与硬件的性能与功能,往往从事这样的工作这是属于设计系统架构环节最为困难的工作。除了以上所提到的之外,基于各个不同的角度进行分析,都能够了解到划分元件、决定设计这两个架构的要素。一个软件系统的元件首先就是属于一种逻辑元件。那么究竟怎样做到在硬件中有效的放置以上所提到的逻辑元件,还有的就是这些元件怎样发挥作用在整个系统的性能、强壮性、可扩展性、灵活性、可靠性等。这也是属于特别重要的信息。比如在一个中等规模的数据库应用系统往往大致存在一百个左右数据表,那么这也就使得设计一个系统往往必须依托一百页规模架构进行文档设计。
往往表示软件架构则是借助于多种架构视图实施。基于本质上进行分析,那么这样的多种架构视图则是选取相应的图形方式将处于架构领域存在着十分重要意义的模型元素予以摘要性的说明。
实施视图:
这主要包含的内容为包含这实施模型及其从模块到包、层的组织形式实施的概览;而且在这一过程中,还存在着把相应的逻辑视图中的包与类往实施视图中的包与分配模块的状况实施描述。
逻辑视图:
这主要的是最为关键的设计类、从这些设计类到包与子系统的组织形式,另外还有的就是这些包与子系统到层的组织形式。
配置视图:
这主要的是描述最为典型的配置平台的各种物理节点,还有的就是往物理节点分配来自于进程视图的任务的情况,往往这一视图仅仅只是在分布式系统。
用例视图:
这主要的是场景与用例。
进程视图:
这主要的是描述进程与线程的涉及的任务,这些任务的配置与交互,还有的就是把设计分配对象与类向任务,往往这一视图仅仅只是出于系统存在着特别高程度并行过中才使用。
Background processing can be best defined by its action. It simply performs tasks in the background of a computer while a computer user performs actions in the foreground of the computer.
后台处理可以通过它的动作来最好地定义。它只是在计算机的后台执行任务,而计算机用户在计算机的前台执行操作。
Background processing can be best defined by its action. It simply performs tasks in the background of a computer while a computer user performs actions in the foreground of the computer. For example, in background processing, a computer user can actively manipulate one application using a keyboard and a computer screen while separate operations are performed at the same time and in the background. In many cases, background processes work completely autonomously and the user isn’t even aware that the processes are being performed.
后台处理可以通过它的动作来最好地定义。它只是在计算机的后台执行任务,而计算机用户在计算机的前台执行操作。例如,在后台处理中,计算机用户可以使用键盘和计算机屏幕主动操作一个应用程序,同时在后台执行单独的操作。在许多情况下,后台进程完全自主地工作,而用户甚至不知道进程正在执行。
Processing data in the background of any computer is an integral part of the functioning of a computer. Backgrounds can be high-priority, same-level priority or low-level priority compared to the application that a user is working with on-screen. As long as background processing is achieved within an acceptable time frame and doesn’t interfere with the activities of the user or the overall functioning of the computer, it can be considered to be successful.
在任何计算机的后台处理数据是计算机功能的一个组成部分。与用户在屏幕上使用的应用程序相比,背景可以是高优先级、同级优先级或低优先级。只要后台处理在可接受的时间范围内完成,并且不干扰用户的活动或计算机的整体功能,就可以认为是成功的。
One popular example of background processing involves the common printer. When a computer user works on a word processor to type up a document, saves it and commands the computer to print it, the command is transferred over to the printer by way of the computer’s background processes. This activity takes place independent of whatever is happening on the computer user’s screen. In fact, a computer user can continue to make modifications to the document, open and type a new document or work in an entirely new application altogether while the computer is engaged in background processing.
后台处理的一个流行示例涉及到通用打印机。当计算机用户在文字处理器上打印文档、保存文档并命令计算机打印文档时,该命令通过计算机的后台进程转移到打印机。这种活动独立于计算机用户屏幕上发生的任何事情。事实上,计算机用户可以继续修改文档,打开并键入一个新的文档,或者在一个全新的应用程序中工作,而计算机正在进行后台处理。
The lack of interaction between computer user and background processes should not be misunderstood to mean that the processes are unimportant. There are certain background processes that are just as important as those applications that are being interacted with in the foreground. Some computers have the ability to prioritize tasks and regulate how much energy is devoted to each. Generally, though, a background process is relatively low priority and has minimal output.
计算机用户和后台进程之间缺乏交互不应该被误解为这些进程不重要。有一些后台进程和那些在前台进行交互的应用程序同样重要。一些计算机有能力对任务进行优先排序,并调节每个任务所需的能量。一般来说,后台进程的优先级相对较低,并且输出很少。
Background processes can be usually categorized as being either a daemon or a compute-intensive task. The average computer user will be more familiar with the work of daemons, as they help take care of common functions like email transferring, web page serving and time synchronization. Their interactions are not with users, but with programs or other computers on a network. They use very little memory and don’t put a large dent in CPU usage, so computer users may work on a machine for years without realizing that these processes exist and are actually taking place while they are concentrating on a task in the computer’s foreground.
后台进程通常可以分类为守护进程或计算密集型任务。一般的计算机用户将更加熟悉守护进程的工作,因为它们有助于处理电子邮件传输、网页服务和时间同步等常见功能。它们不是与用户交互,而是与程序或网络上的其他计算机交互。它们使用的内存很少,而且不会对 CPU 使用造成很大的影响,所以计算机用户可能会在一台机器上工作多年,却没有意识到这些进程的存在,而且实际上是在他们专注于计算机前景中的任务时发生的。
A collaboration diagram, also known as a communication diagram, is an illustration of the relationships and interactions among software objects in the Unified Modeling Language (UML). These diagrams can be used to portray the dynamic behavior of a particular use case and define the role of each object.
协作图,也称为交流图,是统一建模语言中软件对象之间的关系和交互的一个例子。这些图可用于描述特定用例的动态行为,并定义每个对象的角色。
Collaboration diagrams are created by first identifying the structural elements required to carry out the functionality of an interaction. A model is then built using the relationships between those elements. Several vendors offer software for creating and editing collaboration diagrams.
协作图是通过首先确定执行交互功能所需的结构元素来创建的。然后利用这些元素之间的关系建立模型。一些供应商提供用于创建和编辑协作图的软件。
A collaboration diagram resembles a flowchart that portrays the roles, functionality and behavior of individual objects as well as the overall operation of the system in real time. The four major components of a collaboration diagram are:
协作图类似于一个流程图,它描绘了单个对象的角色、功能和行为,以及实时的系统整体操作。协作图的四个主要组成部分是:
Objects- Objects are shown as rectangles with naming labels inside. The naming label follows the convention of object name: 对象-对象显示为带有命名标签的矩形。命名标签遵循对象名称的约定:class name 类名. If an object has a property or state that specifically influences the collaboration, this should also be noted. 。如果对象具有专门影响协作的属性或状态,也应该注意这一点
Actors- Actors are instances that invoke the interaction in the diagram. Each actor has a name and a role, with one actor initiating the entire use case. 参与者------参与者是在图中调用交互的实例。每个参与者都有一个名称和一个角色,由一个参与者启动整个用例
Links- Links connect objects with actors and are depicted using a solid line between two elements. Each link is an instance where messages can be sent. 链接-链接连接对象与演员和描述使用实线之间的两个元素。每个链接都是可以发送消息的实例
messages- Messages between objects are shown as a labeled arrow placed near a link. These messages are communications between objects that convey information about the activity and can include the sequence number. 消息------对象之间的消息显示为放置在链接附近的带标签的箭头。这些消息是对象之间的通信,它们传递有关活动的信息,并且可以包含序列号
The most important objects are placed in the center of the diagram, with all other participating objects branching off. After all objects are placed, links and messages should be added in between.
最重要的对象被放置在关系图的中心,所有其他参与的对象分支。在放置所有对象之后,应该在两者之间添加链接和消息。
Collaboration diagrams should be used when the relationships among objects are crucial to display. A few examples of instances where collaboration diagrams might be helpful include:
当对象之间的关系对于显示至关重要时,应该使用协作关系图。协作图可能有帮助的一些实例包括:
Modeling collaborations, mechanisms or the structural organization within a system design. 在系统设计中为协作、机制或结构组织建模
Providing an overview of collaborating objects within an object-oriented system. 提供面向对象系统中协作对象的概述
Exhibiting many alternative scenarios for the same use case. 显示同一用例的许多可选场景
Demonstrating forward and 向前展示reverse engineering 逆向工程.
Capturing the passage of information between objects. 捕获对象之间的信息通道
Visualizing the complex logic behind an operation. 可视化操作背后的复杂逻辑
However, collaboration diagrams are best suited to the portrayal of simple interactions among relatively small numbers of objects. As the number of objects and messages grows, a collaboration diagram can become difficult to read and use efficiently. Additionally, collaboration diagrams typically exclude descriptive information, such as timing.
然而,协作图最适合描绘相对较少的对象之间的简单交互。随着对象和消息数量的增加,协作关系图可能变得难以阅读和有效使用。此外,协作关系图通常不包含描述性信息,例如时间。
In UML, the two types of interaction diagrams are collaboration and sequence diagrams. While both types use similar information, they display them in separate ways. Collaboration diagrams are used to visualize the structural organization of objects and their interactions. Sequence diagrams, on the other hand, focus on the order of messages that flow between objects. However, in most scenarios, a single figure is not sufficient in describing the behavior of a system and both figures are required.
在 UML 中,两种类型的交互图是协作图和序列图。虽然这两种类型使用相似的信息,但它们以不同的方式显示。协作图用于可视化对象的结构组织及其交互。另一方面,序列图关注对象之间流动的消息的顺序。但是,在大多数情况下,单个图形不足以描述系统的行为,需要两个图形。
下面一张图是一个协作图的实例,创建课程的协作图
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-4vVicPbn-1609755291789)(media/image22.png)]{width=“5.763888888888889in” height=“3.692361111111111in”}
由于协作图和时序图在语意上是相通的,所以可以互相转换,下面是利用ROSE把上面的协作图转换成的时序图的实例:
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-r349AY01-1609755291790)(media/image23.png)]{width=“5.766666666666667in” height=“4.379861111111111in”}
The Business Process Modeling Notation (BPMN) is visual modeling language for business analysis applications and specifying enterprise process workflows, which is an open standard notation for graphical flowcharts that is used to define business process workflows. It is popular and intuitive graphic that can be easily understand by all business stakeholders, including business users, business analysts, software developers, and data architects.
是一个用于业务分析应用程序和指定企业流程工作流的可视化业务流程建模标记法建模语言,它是一个用于定义业务流程工作流的图形流程图的开放标准符号。它是流行和直观的图形,可以很容易地被所有业务涉众理解,包括业务用户、业务分析师、软件开发人员和数据架构师。
BPMN allows us to capture and document business processes of an organization in a clear and consistent way that ensures relevant stakeholders, such as, process owners and business users are involved in the process. Thus, the team can response to any issues identified in the processes more effectively. BPMN provide comprehensive and yet rich notations that can easily be understood by both technical and non-technical stakeholders. Business process modeling provides important benefits to companies and organizations such as the ones listed below.
BPMN 允许我们以一种清晰和一致的方式捕获和记录组织的业务流程,以确保相关的涉众(如流程所有者和业务用户)参与流程。因此,团队可以更有效地响应过程中发现的任何问题。BPMN 提供了全面而丰富的符号,技术和非技术利益相关者都可以很容易地理解。业务流程建模为下面列出的公司和组织提供了重要的好处。
An industry standard developed by the OMG consortium, a not-for-profit industry group 由非营利性行业组织 OMG 联盟开发的行业标准
Provides businesses with the capability of defining and understanding their procedures through Business Process Diagrams 通过业务流程图为企业提供定义和理解其过程的能力
To provide a standard notation that is readily understandable by all business stakeholders 提供所有业务涉众容易理解的标准符号
To bridge the communication gap that frequently occurs between business process design and implementation 弥合业务流程设计和实现之间经常出现的通信差距
Simple to learn yet powerful enough to depict the potential complexities of a business process 学起来很简单,但是足够强大,可以描述业务流程的潜在复杂性
The Goal of BPMN
BPMN 的目标
Technical experts responsible for process implementation 负责过程实施的技术专家
Business analysts who create and improve the processes 创建和改进流程的业务分析师
Managers who monitor and control the processes 监督和控制过程的管理者
Overview of BPMN
BPMN 概述
Knowing how the business operates is the first and the most critical step of business process improvement. Business Process Model and Notation (BPMN), provides a graphical representation of business work flows that anyone, from business analyst to stakeholder, can easily understand; aiding in business process analysis and business process improvements.
了解业务如何运作是业务流程改进的第一步,也是最关键的一步。提供了业务工作流的图形化表示,任何人,从业务分析师到利益相关者,都可以很容易地理解这些业务流程建模标记法; 协助业务流程分析和业务流程改进。
Any process described with BPMN is represented as a number of steps (activities) that are performed consequently or at the same time according to certain business rules. Take a look at the “Place Order online” process which can be used in an on-line store that place orders on the web.
使用 BPMN 描述的任何流程都表示为许多步骤(活动) ,这些步骤(活动)随后或同时根据某些业务规则执行。
BPMN定义了一个业务流程图(Business Process Diagram),该业务流程图基于一个流程图(flowcharting),该流程图被设计用于创建业务流程操作的图形化模型。而一个业务流程模型(Business Process Model),指一个由图形对象(graphical objects)组成的网状图,图形对象包括活动(activities)和用于定义这些活动执行顺序的流程控制器(flow controls)
以下是四种基本的类型:
流对象(Flow)
连接对象(Connection)
泳道(Swimlane)
人工信息(Artifact)
BPMN的开发是减少众多已存在的业务建模工具和标记断层的重要的一步。BPMI标准化组织从许多存在的标记中展示出了专业和经验,且从这些不同的标记中找到了最好的理念形成一套标准的标记语言,众多的标记语言包括UML、Activity Diagram、UML EDOC Business Process、IDEF、ebXML BPSS、RosettaNet以及Event-Process Chains等等。一个好的标准建模标记将会减少业务与IT用户之间的混乱。
另一个驱使BPMN的开发原动力是,历史上由业务人员做出来的业务流程建模从需要系统设计与执行的流程描述中隔离出来,所以有必要将原有的业务流程模型转换为执行模型,而这个转换对于流程拥有者来说容易出错,且很艰难。
为了减少建模技术的断层,开发BPMN的重要目标就是要创建面向业务流程建模标记到面向IT执行语言的一座桥梁。
So what is a use case diagram? A UML use case diagram is the primary form of system/software requirements for a new software program underdeveloped. Use cases specify the expected behavior (what), and not the exact method of making it happen (how). Use cases once specified can be denoted both textual and visual representation (i.e. use case diagram). A key concept of use case modeling is that it helps us design a system from the end user’s perspective. It is an effective technique for communicating system behavior in the user’s terms by specifying all externally visible system behavior.
那么什么是使用案例图呢?对于一个新的软件项目来说,UML 使用案例图是系统/软件需求的主要形式。用例指定预期的行为(什么) ,而不是使其发生的确切方法(如何发生)。一旦指定了用例,就可以同时表示文本和可视化的表示形式(例如使用案例图)。用例建模的一个关键概念是,它帮助我们从最终用户的角度设计系统。通过指定所有外部可见的系统行为,它是以用户的术语进行系统行为通信的一种有效技术。
A use case diagram is usually simple. It does not show the detail of the use cases:
使用案例图通常很简单,它不显示用例的细节:
It only summarizes 它只是概括了some of the relationships 一些关系 between use cases, actors, and systems. 在用例、参与者和系统之间
It does 的确如此not show the order 不要显示命令 in which steps are performed to achieve the goals of each use case. 执行步骤以实现每个用例的目标
As said, a use case diagram should be simple and contains only a few shapes. If yours contain more than 20 use cases, you are probably misusing use case diagram.
如上所述,一个使用案例图应该是简单的,并且只包含几个形状。如果你的包含超过20个用例,那么你很可能是在滥用使用案例图。
The figure below shows the UML diagram hierarchy and the positioning of the UML Use Case Diagram.
Use case diagrams are typically developed in the early stage of development and people often apply use case modeling for the following purposes:
用例图通常是在开发的早期阶段开发的,人们经常将用例建模用于以下目的:
Specify the context of a system 指定系统的上下文
Capture the requirements of a system 捕获系统的需求
Validate a systems architecture 验证系统架构
Drive implementation and generate test cases 驱动实现并生成测试用例
Developed by analysts together with domain experts 由分析师和领域专家共同开发
用例模型是从应用领域(Application domain)的角度,面向用户的一种模型,旨在描述用户眼中(而非程序员眼中)此系统的功能行为。
用例图体现了该系统能够为参与者提供的种种功能以及这些功能之间的联系。要画好一张用例图,需要把握三个元素:参与者(Actor)、用例(Use Case)和用例间的关系(Relationship)。
一、 参与者
参与者代表的是参与使用系统的一类角色,例如,使用者就是实验室管理系统这个系统的参与者。要正确把握参与者,需要注意以下几点:
1. 参与者本身并不属于系统结构之中,位于系统之外;
2. 参与者代表的是一类角色而不是一个具体对象,换言之,你可以说参与者是猪,而不能说参与者是"佩奇";
3. 参与者不一定是人,也可以是另一个外部的系统、环境等等。
UML中用一个小人图形表示参与者。我们给每一个参与者取特定的名字,并可以在文档中对用例进行描述。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-c3CsE1PO-1609755291791)(media/image24.png)]{width=“3.3020833333333335in” height=“2.21875in”}
UML中名为Passenger的参与者
二、 用例
每个用例代表系统能够提供的一类功能,UML中使用一个椭圆形表示用例。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-7iohR53v-1609755291791)(media/image25.png)]{width=“3.5520833333333335in” height=“1.28125in”}
UML中名为Purchase Ticket的用例
每个用例在文档中都需要进行详细说明,说明中需要包含:
1. 用例名称;
2. 用例的参与者:使用该用例的参与者;
3. 用例的进入条件:满足什么条件可以使用该用例;
4. 用例的离开条件:满足什么条件可以结束该用例的使用;
5. 流程:参与者使用该用例的步骤;
6. 特殊需求:包含对用例性能上的需求或者拓展业务。
三、 关系
用例之间的关系只要包括三种,分别是扩展、包含和继承。
1. 扩展
扩展关系是在一个已有用例的基础上扩展新的功能而产生的关系,常用于对特殊情况的补充。比方说,购票"选票->付钱->出票->找零"本身是一个完整用例,但是在过程中可能出现零钱不足、缺票、用户中途取消等特殊状况,处理这些特殊状况的功能就是扩展功能。
扩展功能在UML中用<
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-qBmSDUZN-1609755291792)(media/image26.png)]{width=“5.520833333333333in” height=“3.6979166666666665in”}
UML中扩展关系的应用
2. 包含
包含关系指一个主用例包含子用例。包含关系常用于子用例频繁被使用的情况。例如下图所示的例子,买单次票与买多次用卡的用例中都包含了收费这一子用例,为避免重复书写子用例,我们使用包含关系。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Pq28LWY3-1609755291793)(media/image27.png)]{width=“5.395833333333333in” height=“2.5833333333333335in”}
UML中包含关系的应用
包含关系在UML中用<
3. 继承
处于继承关系中的用例在不同抽象层,其中被继承的一方是继承的一方更概括抽象的概念。例如:主用例是"用户识别",“人脸识别"是用户识别的一种,“指纹识别"也是用户识别的一种。在继承关系中常常出现”…是…的一种”(is a kind of)这样的关系,这可以帮助大家识别继承关系。下面是一个例子:
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-YoODTfVi-1609755291794)(media/image28.png)]{width=“5.635416666666667in” height=“2.9166666666666665in”}
UML中继承关系的应用
在UML中,继承关系由一个空心箭头表示,由继承的一方指向被继承的一方(具体的一方指向抽象的一方)。
在用例图中,用例关系的箭头方向是比较容易出错的一点,我的记忆方法是带入"A extends B",“A includes B” 和 "A inherits B"这样的句型,箭头永远从主语指向宾语。
Timing diagrams focus on conditions changing within and among lifelines along a linear time axis. Timing Diagrams describe behavior of both individual classifiers and interactions of classifiers, focusing attention on time of occurrence of events causing changes in the modeled conditions of the Lifelines.
时间图关注的是生命线内部和生命线之间沿着线性时间轴发生的变化。时序图描述了单个分类器的行为和分类器之间的相互作用,将注意力集中在引起生命线模型条件变化的事件发生的时间上。
State Timeline Representation
状态时间线表示法
Changes from one state to another are represented by a change in the level of the lifeline. For the period of time when the object is a given state, the timeline runs parallel to that state. A change in state appears as a vertical change from one level to another. The cause of the change, as is the case in a state or sequence diagram, is the receipt of a message, an event that causes a change, a condition within the system, or even just the passage of time.
从一个状态到另一个状态的变化表现为生命线级别的变化。对于对象处于给定状态的时间段,时间线与该状态平行运行。状态的变化表现为从一个级别到另一个级别的垂直变化。变化的原因,就像在一个州或时序图,是接收到一个消息,一个事件,导致变化,系统内的条件,甚至只是时间的流逝。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-f6mMiCfg-1609755291795)(media/image29.png)]{width=“5.7625in” height=“3.4916666666666667in”}
Timing Diagram Example
Value lifeline Representation
价值生命线表示法
The figure below shows an alternative notation of UML Timing diagram. It shows the state of the object between two horizontal lines that cross with each other each time the state changes.
下面的图显示了 UML 计时图的另一种表示法。它显示了两条水平线之间的对象状态,这两条线在状态发生变化时相互交叉。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-qHa8pZAU-1609755291796)(media/image30.png)]{width=“5.768055555555556in” height=“2.1458333333333335in”}
Compact view of Timing Diagram
Basic Concepts of Timing Diagrams
时序图的基本概念
Major elements of timing UML diagram - lifeline, timeline, state or condition, message, duration constraint, timing ruler.
时间 UML 图的主要元素------生命线、时间线、状态或条件、消息、持续时间约束、时间标尺。
Lifeline
生命线
A lifeline in a Timing diagram forms a rectangular space within the content area of a frame. Lifeline is a named element which represents an individual participant in the interaction. It is typically aligned horizontally to read from left to right.
时序图中的生命线在框架的内容区域内形成一个矩形空间。生命线是一个命名元素,它表示交互中的个别参与者。它通常是水平对齐的,从左到右阅读。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-vjGV5ACJ-1609755291797)(media/image31.png)]{width=“2.375in” height=“1.0833333333333333in”}
Timing Diagram with One Lifeline
Multiple lifelines may be stacked within the same frame to model the interaction between them.
多个生命线可能被堆放在同一个框架中,以模拟它们之间的交互。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-SJhPiKdk-1609755291798)(media/image32.png)]{width=“2.2395833333333335in” height=“1.5520833333333333in”}
Timing Diagram with Multiple lifelines
State Timeline in Timing Diagram
时序图中的状态时间线
A state or condition timeline represents the set of valid states and time. The states are stacked on the left margin of the lifeline from top to bottom.
状态或条件时间线表示有效状态和时间的集合。这些州从上到下堆放在生命线的左边。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ZW0C5wd4-1609755291798)(media/image33.png)]{width=“5.53125in” height=“2.4375in”}
State Timeline in Timing Diagram
The cause of the change, as is the case in a state or sequence diagram, is the receipt of a message, an event that causes a change, a condition within the system, or even just the passage of time.
变化的原因,就像在一个州或时序图,是接收到一个消息,一个事件,导致变化,系统内的条件,甚至只是时间的流逝。
时序图可以展示对象之间交互的顺序。将交互行为建模为消息传递,通过描述消息是如何在对象间发送和接收的来动态展示对象之间的交互;相对于其他UML图,时序图更强调交互的时间顺序;可以直观的描述并发进程。
Event time: event time is the time that each independent event occurs on its generating device, which is usually embedded in the record before entering Flink.
Event time:事件时间是每个独立事件在其生成设备上发生的时间,通常是在进入到Flink之前就嵌入在记录中的时间。
Processing time:处理时间是指执行相应操作机器的系统时间。当流程序在处理时间上运行时,所有基于时间的操作(如时间窗口)将使用当前运行机器的系统时间。每小时处理时间窗口包括在系统时间每小时内到达的所有指定操作记录。例如:如果应用程序在上午9:15开始运行,第一个小时处理时间窗口将包括上午9:15到10:00之间处理的事件,下一个窗口将包含上午10:00到11:00之间处理的事件,以此类推。
处理时间是最简单的时间概念,不需要流和物理机之间的协调,它有最好的性能和最低的延迟。然而,在分布式和异步环境中,处理时间具有不确定性,因为它容易受到系统之间操作记录传输速度以及中断(计划或其他)的影响,导致数据延迟。
Event time:事件时间是每个独立事件在其生成设备上发生的时间,通常是在进入到Flink之前就嵌入在记录中的时间。并且可以从每个记录中提取事件时间戳,在事件时间中,决于数据产生的时间,而不是当前系统时间。事件时间程序必须指定如何生成事件Watermarks,用来保证事件时间的有序性。Watermarks机制将在下一节中进行描述。
事件时间处理将产生完全一致和确定的结果,无论事件何时到达或顺序如何。但是,除非事件是按顺序(通过时间戳)到达的,否则在等待无序事件时,事件时间处理会产生延迟。因为等待的时间是有限的,这就限制了事件时间应用程序的确定性。
假设所有数据都已到达,事件时间操作将按照预期进行,即使在处理无序延迟的事件或重新处理历史数据,也会产生正确一致的结果。例如,每小时事件时间窗口将包含所有带有属于该小时的事件时间戳的记录,而不管它们到达的顺序如何,也不管它们是在什么时候处理的。(有关延迟事件的更多信息,请参见"延迟事件"一节)。
请注意,有时当事件时间程序实时处理数据时,将使用一些处理时间操作,以确保及时地进行处理。
Ingestion time:摄入时间(Ingestion Time)是事件进入Flink的时间,在源操作中每个记录都会获得源的当前时间作为时间戳,后续基于时间的操作(如: time window)会依赖这个时间戳
摄入时间从概念上来讲是处在事件时间和处理时间之间,与处理时间相比,成本可能会高一点,但是会提供更加可预测的结果。因为摄入时间使用的是固定的时间戳(都是在源处指定的),记录中的不同窗口操作依赖同一个时间戳,而在处理时间中每个窗口操作可能将记录赋给不同的窗口(根据本地的系统时钟和传输时延)。
与事件时间相比,摄入时间程序不能处理任何无序事件或者延迟事件,但是程序无需指定如何产生水印。
与事件时间相比,摄入时间程序不能处理无序的事件或延迟数据,所以不必指定生成Watermark。在内部,摄入时间与事件时间非常相似,但是是自动时间戳分配和自动产生水印。
注意,为了在事件时间中运行此示例,程序需要使用定义事件时间和自己触发watermarks的源数据,或者程序必须在源文件之后注入一个Timestamp Assigner 和 Watermark Generator。这些函数描述了如何获取事件的时间戳以及哪些程度的无序事件流需要展示。
Domain model is a visual representation of conceptual classes or objects in the real world. It is also called concept model, domain object model and analysis object model. It focuses on analyzing the problem domain itself, discovering important business domain concepts, and establishing relationships between business domain concepts.
领域模型是对领域内的概念类或现实世界中对象的可视化表示。又称概念模型、领域对象模型、分析对象模型。它专注于分析问题领域本身,发掘重要的业务领域概念,并建立业务领域概念之间的关系。
In the business object model, business roles represent the roles employees will play, while business entities represent the objects employees will handle. On the one hand, the business object model can be used to determine how business employees will interact to produce the desired results for business actors. On the other hand, the system use case model and design model specify the business information system.
Business modeling and system modeling solve different problems, and the degree of abstraction is also different. Therefore, in general, information systems should not appear directly in the business model.
On the other hand, employees use information systems as business roles to communicate with each other, with the protagonist, and to access business entity information. All links, associations or attributes are supported by a potential information system.
These two types of modeling environments have the following relationships:
As a specific business role, employees correspond to a system protagonist of the information system. If the information system is established so that all the work of the employee in the business use case is supported by a system use case, he is most likely to get the best support. In addition, if the business paradigm is large, the lifetime is long, or the work in multiple independent domains is combined, the information system use case can support the operation of business roles. The objects that employees work on (modeled as business entities) are often represented in information systems. In the object model of information system, these business entities appear as entity classes. The association relationship and aggregation relationship between business entities often lead to the corresponding association and aggregation relationship between entity classes in the design model. Therefore, system use cases access and manipulate entity classes in the design model, which represent business entities accessed by supported business use cases. Finally, the business protagonist who directly uses the business information system also becomes the system protagonist of the information system. These relationships are critical when determining requirements for business supporting information systems.
在业务对象模型中,业务角色代表雇员将担当的角色,而业务实体则代表雇员将处理的对象。一方面,可以使用业务对象模型来确定业务雇员将如何进行交互,以产生业务主角所期望的结果。另一方面,系统用例模型和设计模型指定了业务的信息系统。
业务建模和系统建模解决不同的问题,其抽象程度也不一样。所以一般而言,信息系统不应该直接出现在业务模型中。
另一方面,雇员作为业务角色来使用信息系统,实现相互之间的通信、与主角的通信以及对业务实体信息进行访问。所有的链接、关联关系或属性都有某个潜在的信息系统对其进行支持。
这两类建模环境有以下关系:
作为特定业务角色的雇员与信息系统的一个系统主角相对应。如果建立的信息系统使该雇员在业务用例中的所有工作都得到一个系统用例的支持,则他最有可能得到最好的支持。 另外,如果业务用例规模大、生存期长或者合并了多个独立领域中的工作,信息系统用例将可以支持业务角色的操作。 雇员工作的对象(建模为业务实体)常在信息系统中得到表现。在信息系统的对象模型中,这些业务实体作为实体类出现。业务实体之间的关联关系和聚合关系常常使设计模型中实体类之间产生对应的关联关系和聚合关系。 因此,系统用例访问并操作设计模型中的实体类,这些实体类代表由被支持业务用例访问的业务实体。最后,直接使用业务信息系统的业务主角也成为信息系统的系统主角。 当确定对支持业务的信息系统的需求时,这些关系十分关键。
业务对象模型(也叫领域模型 domain model)是描述业务用例实现的对象模型。它是对业务角色和业务实体之间应该如何联系和协作以执行业务的一种抽象。业务对象模型从业务角色内部的观点定义了业务用例。该模型为产生预期效果确定了业务人员以及他们处理和使用的对象(“业务类和对象”)之间应该具有的静态和动态关系。它注重业务中承担的角色及其当前职责。这些模型类的对象组合在一起可以执行所有的业务用例
业务角色显示了一个人承担的一系列职责。业务实体表示使用或产生的可交付工件、资源和事件。业务用例实现显示了协作的业务角色和业务实体如何执行某个工作流程。使用以下几种图来记录业务用例实现: 图显示参与的业务角色和业务实体。活动图,其中泳道显示业务角色的职责,而对象流显示如何在工作流程中使用业务实体。 序列图描述业务角色和业务主角之间交互的详细情况,并显示如何在业务用例执行过程中访问业务实体。
例如,经过分析,我们的实验室设备管理系统中,有设备是实体,管理员是管理实验室设备这个业务的一个角色,教师和学生也是业务中的角色,由此就可以建立起实验室设备管理的领域模型
经过一个学期的软件需求分析与建模的学习,对于软件工程与需求分析的认识更深了,从中学到了许多东西,例如UML各种图是什么意思,每个图该怎么画,如何去理解等等,有了这些知识,对于我们项目今后的发展提供了坚实的基础,通过对需求分析与建模的学习,我们可以更好得进行项目的准备,开发和管理,既然学习了这么多的只是,我认为应当把他们好好利用起来,给我们的项目增加价值,可以针对我们的项目,把之前书写的需求分析文档再次完善一下,利用上后来学习的东西,我们小组的项目是实验室设备管理系统,经过我们的切身体会,该系统的应用前景还是十分广泛的,是一个高校实验室所必备的系统,因此对我们小组的发展建议有下面几点
利用所学内容完善好需求分析
根据需求分析的内容,分析实现系统所需要的资源以及技术
实现该系统的大部分功能
结合系统的商业价值分析,将系统朝着商用的方向发展
ist of the information system. If the information system is established so that all the work of the employee in the business use case is supported by a system use case, he is most likely to get the best support. In addition, if the business paradigm is large, the lifetime is long, or the work in multiple independent domains is combined, the information system use case can support the operation of business roles. The objects that employees work on (modeled as business entities) are often represented in information systems. In the object model of information system, these business entities appear as entity classes. The association relationship and aggregation relationship between business entities often lead to the corresponding association and aggregation relationship between entity classes in the design model. Therefore, system use cases access and manipulate entity classes in the design model, which represent business entities accessed by supported business use cases. Finally, the business protagonist who directly uses the business information system also becomes the system protagonist of the information system. These relationships are critical when determining requirements for business supporting information systems.
在业务对象模型中,业务角色代表雇员将担当的角色,而业务实体则代表雇员将处理的对象。一方面,可以使用业务对象模型来确定业务雇员将如何进行交互,以产生业务主角所期望的结果。另一方面,系统用例模型和设计模型指定了业务的信息系统。
业务建模和系统建模解决不同的问题,其抽象程度也不一样。所以一般而言,信息系统不应该直接出现在业务模型中。
另一方面,雇员作为业务角色来使用信息系统,实现相互之间的通信、与主角的通信以及对业务实体信息进行访问。所有的链接、关联关系或属性都有某个潜在的信息系统对其进行支持。
这两类建模环境有以下关系:
作为特定业务角色的雇员与信息系统的一个系统主角相对应。如果建立的信息系统使该雇员在业务用例中的所有工作都得到一个系统用例的支持,则他最有可能得到最好的支持。 另外,如果业务用例规模大、生存期长或者合并了多个独立领域中的工作,信息系统用例将可以支持业务角色的操作。 雇员工作的对象(建模为业务实体)常在信息系统中得到表现。在信息系统的对象模型中,这些业务实体作为实体类出现。业务实体之间的关联关系和聚合关系常常使设计模型中实体类之间产生对应的关联关系和聚合关系。 因此,系统用例访问并操作设计模型中的实体类,这些实体类代表由被支持业务用例访问的业务实体。最后,直接使用业务信息系统的业务主角也成为信息系统的系统主角。 当确定对支持业务的信息系统的需求时,这些关系十分关键。
业务对象模型(也叫领域模型 domain model)是描述业务用例实现的对象模型。它是对业务角色和业务实体之间应该如何联系和协作以执行业务的一种抽象。业务对象模型从业务角色内部的观点定义了业务用例。该模型为产生预期效果确定了业务人员以及他们处理和使用的对象(“业务类和对象”)之间应该具有的静态和动态关系。它注重业务中承担的角色及其当前职责。这些模型类的对象组合在一起可以执行所有的业务用例
业务角色显示了一个人承担的一系列职责。业务实体表示使用或产生的可交付工件、资源和事件。业务用例实现显示了协作的业务角色和业务实体如何执行某个工作流程。使用以下几种图来记录业务用例实现: 图显示参与的业务角色和业务实体。活动图,其中泳道显示业务角色的职责,而对象流显示如何在工作流程中使用业务实体。 序列图描述业务角色和业务主角之间交互的详细情况,并显示如何在业务用例执行过程中访问业务实体。
例如,经过分析,我们的实验室设备管理系统中,有设备是实体,管理员是管理实验室设备这个业务的一个角色,教师和学生也是业务中的角色,由此就可以建立起实验室设备管理的领域模型
经过一个学期的软件需求分析与建模的学习,对于软件工程与需求分析的认识更深了,从中学到了许多东西,例如UML各种图是什么意思,每个图该怎么画,如何去理解等等,有了这些知识,对于我们项目今后的发展提供了坚实的基础,通过对需求分析与建模的学习,我们可以更好得进行项目的准备,开发和管理,既然学习了这么多的只是,我认为应当把他们好好利用起来,给我们的项目增加价值,可以针对我们的项目,把之前书写的需求分析文档再次完善一下,利用上后来学习的东西,我们小组的项目是实验室设备管理系统,经过我们的切身体会,该系统的应用前景还是十分广泛的,是一个高校实验室所必备的系统,因此对我们小组的发展建议有下面几点
利用所学内容完善好需求分析
根据需求分析的内容,分析实现系统所需要的资源以及技术
实现该系统的大部分功能
结合系统的商业价值分析,将系统朝着商用的方向发展