提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档

---

1.实体关系图(Entity relationship diagram)

1.1参考网站
https://www.edrawsoft.com/entity-relationship-diagrams.html
https://www.sisense.com/glossary/entity-relationship-diagram/
1.2名词定义
An entity relationship diagram describes how entities relate to each other. In simple terms, it’s a picture or a framework of your business or a certain business process. (Learn more about business process modeling). Entities are the things we need to store data about. It’s an aspect of your business that needs to store data, such as a department - or sales, revenues, maybe clients.
An entity-relationship diagram (ERD) is a data modeling technique that graphically illustrates an information system’ s entities and the relationships between those entities. An ERD is a conceptual and representational model of data used to represent the entity framework infrastructure.
An entity relationship diagram gives a snapshot of how these entities relate to each other. You could call it the blueprint that underpins your business architecture, offering a visual representation of the relationships between different sets of data (entities).In the diagram, entities are represented by boxes with lines linking them to various attributes, which describe the entity’s qualities or characteristics.Everything links up according to the relationships between the entities – or how they interact with each other. Relationships are sometimes referred to as cardinalities, which describes the interactions numerically – but let’s simply call them relationships
实体关系图描述实体如何相互关联。简单地说，它是您的业务或某个业务流程的一个图片或框架。(了解有关业务流程建模的更多信息)。实体是我们需要存储数据的东西。它是业务的一个方面，需要存储数据，例如部门、销售、收入、客户等。
实体关系图(ERD)是一种数据建模技术，它以图形方式说明信息系统的实体以及这些实体之间的关系。ERD是用于表示实体框架基础结构的数据的概念和表示模型。
实体关系图提供了这些实体如何相互关联的快照。你可以称之为支撑业务架构的蓝图，它提供了不同数据集（实体）之间关系的可视化表示，描述实体的质量或特征。一切根据实体之间的关系连接起来，或者它们如何相互作用。关系有时被称为基数（cardinality），它用数字来描述相互作用，但让我们简单地称之为关系。
实体：具有公共性质的可相互区别的现实世界对象的集合，可以是具体的，也可以是抽象的概念或联系。
属性：实体所具有的模拟特性，一个实体可由若干个属性来刻画。
关系：数据对象彼此之间相互联系的方式称为关系。
关系连接线：用来连接实体与关系的线段。

1.3项目联系
我们的公司人事管理系统，主要有三个实体，公司人事管理员，公司老板和公司员工。
在公司中只能有一个公司老板，和若干个公司员工，公司老板可以管理员工，公司老板和公司员工是一对多的关系。

在我们系统中公司人事管理员是只有1个，公司人事管理员可以管理公司员工，公司人事管理员和公司员工的关系是一对多。

公司人事管理员拥有最高高权限，也可以更新公司老板的信息，即公司人事管理员可以管理公司员工，公司人事管理员和公司老板是一对一的关系。

多实体之间的关系
定义：在两个以上多个实体集之间，当一个实体集与其它实体集之间均(注意是均)存在相同关系，而其它实体集之间均(注意是均)没有关系时，这种关系才称之为多个实体集之间的关系。在以上三个实体中，我们系统主要的三个实体是不存在这种关系的，但是他们三个实体存在的三个实体两两对应的关系。

---

2.可维护性(Maintainability)

2.1参考网站
https://www.oreilly.com/content/what-is-maintainability/
2.2名词定义
Maintainability (how easily a system can be modified) is one characteristic of software quality. Performance (how slow or fast a system produces its output) is another.
The international standard ISO/IEC 25010:2011 (which we simply call ISO 25010 in this book1) breaks down software quality into eight characteristics:maintainability,functional suitability,performance efficiency,compatibility,usability,reliability,security, and portability. This book focuses exclusively on maintainability.
The Four Types of Software Maintenance
Software maintenance is not about fixing wear and tear. Software is not physical, and therefore it does not degrade by itself the way physical things do. Yet most software systems are modified all the time after they have been delivered. This is what software maintenance is about. Four types of software maintenance can be distinguished:
Bugs are discovered and have to be fixed (this is called corrective maintenance).
The system has to be adapted to changes in the environment in which it operates—for example, upgrades of the operating system or technologies (this is called adaptive maintenance).
Users of the system (and/or other stakeholders) have new or changed requirements (this is called perfective maintenance).
Ways are identified to increase quality or prevent future bugs from occurring (this is called preventive maintenance).
Maintainability Has Significant Business Impact
In software development, the maintenance phase of a software system often spans 10 years or more. During most of this time, there is a continuous stream of issues that need to be resolved (corrective and adaptive maintenance) and enhancement requests that have to be met (perfective maintenance). The efficiency and effectiveness with which issues can be resolved and enhancements can be realized is therefore important for stakeholders.
Maintenance efforts are reduced when issue resolution and enhancements can be performed quickly and easily. If efficient maintenance leads to less maintenance personnel (developers), it also lowers maintenance costs. When the number of developers stays the same, with efficient maintenance they have more time for other tasks, such as building new functionality. Fast enhancements mean shorter time-to-market of new products and services supported by the system. For both issue resolution and enhancements, it holds that if they are slow and troublesome, deadlines may not be met or the system may become unusable.
可维护性（系统如何容易修改）是软件质量的一个特点。 性能（系统产生输出的速度是多么慢或快）是另一种。
国际标准ISO/IEC25010：2011(我们在本书中简单地称之为ISO25010)将软件质量分为八个特征：可维护性、功能适用性、性能efficiency，compatibility，usability，reliability，security，可移植性。 这本书只关注可维护性。
软件维护的四种类型
软件维护不是固定磨损。 软件不是物理的，因此它本身不会像物理事物那样退化。 然而，大多数软件系统在交付后一直被修改。 这就是软件维护的内容。 四种类型的软件维护可以区分：
1.凸耳被发现，必须被修复（这称为维护）。
2.系统必须适应其运行环境的变化-例如操作系统或技术的升级（这称为适应性维护）。
3.系统的用户（和/或其他利益相关者)有新的或更改的需求(这称为有效维护）。
4.确定了提高质量或防止未来错误发生的方法（这称为预防性维护）。
可维护性具有显著的业务影响
在软件开发中，软件系统的维护阶段通常跨越10年或更长时间。 在大多数情况下，需要解决的问题（纠正和适应性维护)和必须满足的增强请求(完善性维护)源源不断）。 因此，能够解决问题和实现改进的效率和效力对于利益攸关方来说是重要的。
当问题解决和增强可以快速和容易地执行时，维护工作就会减少。 如果高效的维护导致维护人员（开发人员）减少，也会降低维护成本。 当开发人员的数量保持不变时，通过有效的维护，他们有更多的时间来完成其他任务，例如构建新的功能。 快速增强意味着系统支持的新产品和服务的上市时间更短。 对于问题解决和增强，它认为，如果它们是缓慢和麻烦的，最后期限可能无法满足，或者系统可能无法使用。
2.3项目联系
维护工作是在项目开发后进行的，在项目开发出来后，进行测试到发行，在这期间发现的问题，用户反馈的问题，进行代码的的维护解决。我们项目的维护性在项目开发时就已经在考虑，即使这个项目没开发出来，但是这是必要的。在每一个阶段的过程中都对反馈进行维护修改，更好的提升项目的商业模式。如果项目的可维护性是如此低，它不再可能有效地修改它们-甚至在系统进入生产之前。修改带来的bug比解决的bug还多。开发花费了如此长的时间，以至于业务环境(因此，用户需求)已经发生了变化。需要更多的修改，这引入了更多的buq。通常情况下，这样的系统在发布1.0版本之前就已经被淘汰了。

1.可维护性最大的好处来自于遵循简单的指导原则。
2.可维护性不是事后的想法，而是应该从开发项目的一开始就考虑到的。每个人的贡献都很重要。
3.有些违规行为比其他的更严重。软件系统越符合quidelines，它就越容易维护。

---

3.客户要求规范（Customer requirements specification）

3.1参考网站
https://simplicable.com/new/customer-requirements
3.2名词定义
A customer requirementis a specification that originates with customers as opposed to internal stakeholders. This can include both functional and non-functional requirements for products, services and experiences. Customer requirements may be documented directly by customers themselves or collected and refined by ar internal business analyst or market research team. The following are common types of customer requirement.
Voice of the Customer
Identifying customers that represent your target market and collecting needs,expectation sand ideas with methods such as a focus group or ladder interview.
Lead User
Engaging lead users who represent your customers with cutting edge needs. For example, a snowboard manufacturer may engage professional snowboarders to capture ideas for a design.
Intermediaries
Collecting requirements from customers other than endcustomers such as wholesalers. retailers, manufacturers or value-added resellers. For example, an OEM zipper manufacturer may collect requirements from a sportswear manufacturer for a new type of zipper.
Large Accounts
Products and services that are sold on a business-to-business basis may directly collect requirements from large accounts. For example, a software company that gets 40% of its revenue from five customers might allow those customers to directly submit requests for features.
客户需求的规范源于客户，而不是内部利益相关者。这包括产品、服务和体验的功能性和非功能性需求。客户需求可以由客户自己直接记录，也可以由ar内部业务分析和市场研究团队收集和细化。以下是客户需求的常见类型。
客户的声音
识别代表你的目标市场和收集需求的客户，用焦点小组或阶梯面试等方法来期望沙想法。
主要用户
让代表你的客户的领先用户参与到最尖端的需求中。 例如，滑雪板制造商可能会聘请专业的滑雪板师来捕捉设计的想法。
中介人
从终端客户（如批发商）以外的客户收集需求。 零售商、制造商或增值经销商。 例如，OEM拉链制造商可以从运动服装制造商那里收集对新型拉链的要求。
大额账户
在企业对企业的基础上销售的产品和服务可以直接从大型帐户收集需求。 例如，一个从5个客户那里获得40%收入的软件公司可能会允许这些客户直接提交功能请求。
3.3项目联系
硬数据采样结果分析
由采样结果分析得出，不管是老板、信息管理员还是普通用户都觉得公司传统的用户信息管理存在较大的问题，如不方便，不快捷，信息存在较大误差等。有略微超过半数的人使用过信息管理类软件，其他人没使用过，且绝大多数人是会尝试信息管理类软件的，说明信息管理类软件有进一步普及的空间。理想中的信息管理软件特点里简洁轻量、易于上手和精准快捷最为用户看重，许多用户也提出了自己期望的功能，其中激励功能、小目标模板期望较多，在开发过程中在有余力的情况下可以考虑实现。
展开用户需求获取
场景描述：人事部门的核心职能是通过对人力资源的引进、开发及管理来建立一个结构合理的分工协作化组织，以完善公司内部的人力资源结构，发挥人力资源的最大的效应。根据公司经营情况、人力资源外部环境、人力资源供给、需求状况制定人力资源规划（包括招聘、培训开发、考核、调配及薪酬福利规划），根据考评结果作出辞退、降职、内调。人事信息部、薪酬部及相关管理、业务。人事部对公司内部各种业务管理。
用户需求
管理员可在本系统中对公司内部人员进行资源调配，信息管理等操作。
公司员工可在本系统中修改个人信息和查看他人基本信息，以及对上级提议等操作。

---

4.需求基线（Requirements baseline）

4.1参考网站
https://www.jamasoftware.com/blog/defining-requirement-baseline/
4.2名词定义
What is a Requirements Baseline?
A requirements baseline is a snapshot in time that represents an agreed-upon, reviewed, and approved set of requirements that have been committed to a specific product release.
That “release” could be a complete delivered product or any interim development increment of the product. When stakeholders “sign off” on requirements, what they’re really doing is agreeing and committing to a specific requirements baseline (whether they think of it in those terms or not).
Once the project team establishes a requirements baseline, the team should follow a pragmatic change control process to make good business and technical decisions about adding newly-requested functionality and altering or deleting existing requirements.
A change control process is not about stifling change; it’s about providing decision-makers with the information that will let them make timely and appropriate decisions to modify the planned functionality. That planned functionality is the baseline.
Typically, a baseline is also given a unique name so that all the project participants can refer to it unambiguously. And good configuration management practices allow the team to reconstruct accurately any previous baseline and all its components.
需求基线是表示已提交到特定产品版本的已商定、已审核和批准的一组需求的时间快照。“发布”可以是一个完整的交付产品，也可以是产品的任何临时开发增量。当涉众“签署”需求时，他们真正做的是同意并承诺一个特定的需求基线（不管他们是否用这些术语来考虑）。一旦项目团队建立了一个需求基线，团队就应该遵循一个实用的变更控制过程来做出关于添加新请求的功能和更改或删除现有需求的良好的业务和技术决策。
变更控制过程并不是要扼杀变更，而是要向决策者提供信息，使他们能够及时做出适当的决策，以修改计划的功能。计划的功能是基线。
通常情况下，项目的所有参与者都可以明确地引用一个唯一的项目名称。良好的配置管理实践允许团队准确地重建任何先前的基线及其所有组件。
在定义需求基线之前要考虑的因素：
业务规则 确定是否已识别影响系统的业务规则，以及是否指定了强制执行或遵守这些规则的功能。
变更控制 确保有一个实际的变更控制流程来处理需求变更，并且变更控制委员会已经被组装和特许。确保您计划使用的变更控制工具已经就位并配置好，并且工具用户已经过培训。
客户
观点 请与您的主要客户代表联系，看看他们的需求自您上次发言以来是否发生了变化。新的商业规则开始发挥作用了吗？现有规则是否已修改？优先事项有没有改变？有没有发现有不同需求的新客户？
接口 查看功能是否已定义为处理用户、其他软件系统、硬件组件和通信服务的所有已识别的外部接口。
模型验证 与用户代表一起检查任何分析模型，也许通过遍历测试用例，看看基于这些模型的系统是否允许用户执行必要的活动。
原型 如果你创建了原型，是否有合适的客户对它们进行了评估？BA是否使用所获得的知识来修订SRS？
对齐 检查所定义的需求集是否有可能实现项目的业务目标。寻找业务需求、用户需求和功能需求之间的一致性。
评论 让几个需求的下游消费者对其进行评审。这些消费者包括设计人员、程序员、测试人员、文档和帮助编写者、人为因素专家，以及任何将自己的工作建立在需求基础上的人。
范围 确认基线的所有需求都在当前定义的项目范围内。这个范围可能已经改变了，因为它最初是在项目早期定义的。
TBDs 扫描文档以查找TBD（详细信息待定）。TBD代表了有待完成的需求开发工作。
模板 确保SRS文档模板的每个部分都已填充。或者，寻找某些部分不适用于本项目的迹象。常见的疏忽是质量要求、约束和假设。
用户类 查看您是否从为产品标识的所有用户类的适当代表处收到了输入。
可验证性 确定如何判断每个需求是否得到了正确的实现。用户接受标准对此很有帮助。
4.3项目联系
需求基线（Requirements baseline）是团队成员已经承诺将在某特定产品版本中实现的功能性和非功能性需求的一组集合。在需求分析的建立下了阿，我们项目的公司人事管理系统已经确立了功能的雏形。
主要的功能分布在两个UI（User Interface）——管理员UI和用户UI
企业人事用户管理部门——即管理员以管理员权限登录系统，并在此系统中完成各项管理事务。 
管理员录入初始信息，包括职务名称、部门名称、员工的资料，生产基本工资信息。 
当职位变动时，由人事主管修改相关信息，并重新生成基本工资信息。 每日考勤情、病休假等情况记录在案，月末录入考勤与评价情况，自动计算出该月工资。
公司员工可以用户的权限登录该系统，查询和修改自己的员工资料，和工资信息（只可查询），并且，可在系统中请假、休假等，向上级请示自身情况。
这些都是主要的功能，而其他的尚未确立，防止需求的变化给程序架构造成重大影响。
管理员UI
人事管理：人事档案管理、考勤管理、考核管理、调动管理、职称评定、奖惩管理和人事统计。 
工资管理：职务设定、基本工资设定、工资表生成、工资表查询、工资奖惩、月末工资处理。 
综合管理：部门管理、假期与出差管理、员工聘用合同与通知。
系统管理：数据备份与还原、系统初始化。 
用户管理：用户管理、权限设置。
用户UI
用户管理：自身档案管理、考勤管理、考核管理、调动管理、职称评定、奖惩管理和人事统计。 
工资查看：职务设定、基本工资设定、工资表生成、工资表查询、工资奖惩、月末工资处理。
综合管理：部门管理、假期与出差管理、员工聘用合同与通知。

---

5.容器层次结构(containment hierarchy)

5.1参考网站
https://www.sciencedirect.com/topics/computer-science/containment-hierarchy
5.2名词定义
Every top-level container indirectly contains an intermediate container known as a content pane.For most programs, you don’t need to know what’s between a top-level container and its content pane.
As a rule, the content pane contains, directly or indirectly,all of the visible components in the window’s GUI.The big exception to the rule is that if the top-level container has a menu bar, then by convention the menu bar goes in a special place outside of the content pane.
To add a component to a container,you use one of the various forms of the add method.The add method has at least one argument – the component to be added.Sometimes an additional argument is required to provide layout information.For example,the last line of the following code sample specifies that the panel should be in the center of the its container (the content pane).For more information about the add method,see [PENDING: layout lesson, I think].Here is the code that adds the button and label to the panel, and the panel to the content pane
Containment hierarchy in a database system
A method and system for storing and retrieving data in a database system includes associating a plurality of entities in a child/parent hierarchy. The entities are further grouped in types of similar properties, wherein each entity has a unique identifiable position within the child/parent space. References are made to types and properties of the entities in order to store and retrieve associated data about the entity, where the types and properties are mapped to tables of the database.
每个顶级容器间接包含一个中间容器，称为内容面板。对于大多数程序，你不需要知道顶级容器及其内容窗格之间的内容。
通常，内容窗格直接或间接地包含窗口GUI中的所有可见组件。该规则最大的例外是，如果顶级容器是菜单栏，那么按照惯例，菜单栏位于内容窗格之外的特殊位置。
要将组件添加到容器中，可以使用add方法添加方法至少有一个参数–要添加的组件。有时需要附加参数来提供布局信息。例如，以下代码示例的最后一行指定面板应位于其容器（内容窗格）的中心。
数据库系统中的容器层次结构
一种用于在数据库系统中存储和检索数据的方法和系统，包括将子/父层次结构中的多个实体关联起来。这些实体被进一步分组为类似的属性类型，其中每个实体在子/父空间中具有唯一的可识别位置。引用实体的类型和属性，以便存储和检索有关实体的关联数据，其中类型和属性映射到数据库的表。
5.3项目联系
本项目的层次结构图如下，组织分级层次结构，内容信息过多，故未在图中展示，每个实体中的属性大致一样，分别为ID、部门号等，各个阶层以上下及形式，一层套一层，形成有组织的层次结构。方便管理。

---

6.统一建模语言( Unified Modeling Language(UML))

6.1参考网站
https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-uml/
6.2名词定义
UML, short for Unified Modeling Language, is a standardized modeling language consisting of an integrated set of diagrams, developed to help system and software developers for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems. The UML represents a collection of best engineering practices that have proven successful in the modeling of large and complex systems. The UML is a very important part of developing object oriented software and the software development process. The UML uses mostly graphical notations to express the design of software projects. Using the UML helps project teams communicate, explore potential designs, and validate the architectural design of the software.
UML，简称统一建模语言，是一种标准化的建模语言，由一组集成的图表组成，用于帮助系统和软件开发人员指定、可视化、构造和记录软件系统的构件，以及用于业务建模和其他非软件系统。 UML代表了在大型和复杂系统建模中被证明是成功的最佳工程实践的集合。 UML是开发面向对象软件和软件开发过程的重要组成部分。 UML主要使用图形符号来表示软件项目的设计。 使用UML可以帮助项目团队进行沟通，探索潜在的设计，并验证软件的体系结构设计。
结构图显示了系统的静态结构及其在不同抽象和实现级别上的各个部分，以及它们之间的相互关系。结构图中的元素表示系统有意义的概念，可能包括抽象概念、现实世界概念和实现概念，结构图有七种类型，如下所示：
类图、组件图、部署图、对象图、包装示意图、组合结构图、剖面图
行为图显示动态行为一个系统中的对象，它可以描述为对系统的一系列改变时间，共有七种类型的行为图，如下所示：
用例图、活动图、状态机图、序列图、通信图、交互概览图、时序图
UML2.2的图表层次结构

6.3项目联系
本项目在设计过程中也应用了UML，在设计开发过程更好的理解项目，项目的图都是用EA软件画出来的的，本报告中也包含了许多本项目的类图，时序图、包图和组织结构图等等。
随着软件对许多公司的战略价值的增加，该行业正在寻找自动化软件生产、提高质量、减少成本和上市时间的技术。这些技术包括组件技术、可视化编程、模式和框架。随着系统范围和规模的增加，企业还寻求技术来管理系统的复杂性。特别是，他们认识到需要解决重复出现的体系结构问题，如物理分布、并发、复制、安全、负载平衡和容错。此外，万维网的开发虽然使一些事情变得简单，但也加剧了这些架构问题。统一建模语言（UML）就是为了响应这些需求而设计的。

---

7.上下文关系图（context diagram）

7.1参考网站
https://www.edrawmax.com/context-diagram/
7.2名词定义
Context Diagram Also referred to as the Level O Data Flow Diagram, the Context diagram is the highest level in a Data Flow Diagram. It is a tool popular among Business Analysts who use it to understand the details and boundaries of the system to be designed in a project. It points out the flow of information between the system and external components.
It is made up of a context bubble, first drawn in the middle of the chart. It is usually a circle shape that represents a conceptual boundary that encloses a group of interconnected processes and activities of a project. The nitty-gritty details of the internal structure of a system are masked in a context diagram since it is strictly a high-level view of the system. This process is called information hiding.
A context diagram makes part of the requirements document in a project. Unlike other project diagrams, the Context diagram is not for use by the engineers/technicians but the project stakeholders. It, therefore, should be laid out in simple and understandable language for easy understanding of the items by the stakeholders when they analyze it.
上下文关系图(context diagram)用于表示待开发的系统，一般在项目的前期使用；范围图通过描述待开发的系统以及与之交互的外部实体，来厘清系统的边界和范围。
也称为O级数据流程图，上下文图是数据流程图中的最高级别。 它是一种在商业分析师中流行的工具，他们使用它来了解项目中要设计的系统的细节和边界。 它指出了系统与外部组件之间的信息流。
它由一个上下文气泡组成，首先在图表的中间绘制。 它通常是一个圆圈形状，它代表一个概念边界，包含一组相互关联的过程和项目的活动。 系统内部结构的细节在上下文图中被掩盖，因为它严格地说是系统的高级视图。 这个过程称为信息隐藏。
上下文图是项目中需求文档的一部分。 与其他项目图不同，Context图不是供工程师/技术人员使用，而是供项目涉众使用。 因此，应以简单易懂的语言加以阐述，以便利益攸关方在分析项目时容易理解。
7.3项目联系
本项目的上下文图描述了分配和存储员工信息的计算机化系统中的必要组件。它帮助公司老板管理他们的员工信息和公司的业务流程，允许他们更新他们的信息，并使他们在他们的系统中信息上可见。
上下文图用于显示公司人事管理系统软件和与其交互的硬件。箭头指示在软件和每个硬件组件之间流动的数据的方向和类型。
用于显示由老板、员工、管理层和请假系统组成的外部组件之间的关系。它非常适合于确保所有参与方都在同一页面上，并且在不同的高级层次上定义业务项目的范围。

---

8.模型的行为侧重面（behavioral model aspect）

8.1参考网站
https://file.scirp.org/Html/29504.html
8.2名词定义
Aspect oriented development paradigm gives the idea of the separation of concerns. Separation of concerns is not a new idea. Parnas in 1972 gave an idea that a system should be decomposed in modules so that the system should be easy to create, implement, verify and evolve.Each module should hide an aspect of the system that should be evolved independent of the other module. In other words he gave an idea to identify the independent concerns. In the consequence of this research object oriented programming is developed.These crosscutting concerns are cause of the code tangling and code scattering. In code tangling to implement one concern we have to write the code in different modules. In code scattering one piece of code is written in different classes. To address this issue we use aspect-oriented programming. Core concerns can be implemented in any object-oriented language. To implement cross cutting concerns we use aspects.
Aspect oriented software development is an emerging paradigm of software development. The notion of this technique is separation of concerns which means to implement each concern in a single object in object oriented programming but still there are concerns which are distributed on different objects and are called crosscutting concerns while another form is Core concerns are the core functionality provided by the system but crosscutting concerns are the concerns like logging, performance etc. Modeling of aspect oriented software is different from the normal modeling of object-oriented or procedural language software, because aspects don’t have the independent identity or existence and they are tightly coupled to their woven context so it is difficult to model them. The one aim of our research paper is to explore the domain of Modeling of the aspect oriented software. The goal of this research paper is to give a UML Behavioral modeling techniques in the domain of aspect oriented software development. This technique of generating UML Behavioral Model for aspects will give better understating of separations concerns.
面向方面的发展范式给出了关注点分离的思想。 分离关切不是一个新想法。 在1972年，Parnas提出了一个想法，即系统应该被分解成模块，以便于系统的创建、实现、验证和进化。 每个模块应该隐藏系统的一个方面，该方面应该独立于其他模块而演化。 换句话说，他提出了一个确定独立关切的想法。 在此基础上，开发了面向对象编程。 这些横切问题是代码纠缠和代码散射的原因。 为了实现一个问题，我们需要在不同的模块中编写代码。 在代码散射中，一段代码是用不同的类编写的。 为了解决这个问题，我们使用面向方面的编程。 核心关注点可以用任何面向对象的语言实现。 为了实现交叉关注，我们使用方面。
面向方面的软件开发是一种新兴的软件开发范式。 这种技术的概念是分离关注点，这意味着在面向对象编程中实现单个对象中的每个关注点，但仍然存在分布在不同对象上的关注点，称为交叉关注点，而另一种形式是核心关注点是系统提供的核心功能，但交叉关注点是诸如日志记录、性能等问题。 面向方面软件的建模不同于面向对象或过程语言软件的正常建模，因为方面没有独立的身份或存在，并且它们与它们编织的上下文紧密耦合，因此很难对它们进行建模。 本文的目的之一是探索面向方面软件的建模领域。 本文的目的是在面向方面的软件开发领域中给出一种UML行为建模技术。 这种为各个方面生成UML行为模型的技术将更好地低估分离问题。
模型的行为侧重面强调系统中实例行为的模型侧重面，包括其方法、协作和状态历史记录。
8.3项目联系
在每个模型中，都要侧重点表达自己的图表要表达的意思，以下图为例，这是一个层次视角(Layered Viewpoint) 的一部分，在层次视角中侧重点表达某个层次的功能内容以及步骤本项目的登记用户信息功能。

---

9.程序表（sequence diagram）

9.1参考网站
https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-sequence-diagram/
9.2名词定义
UML Sequence Diagrams are interaction diagrams that detail how operations are carried out. They capture the interaction between objects in the context of a collaboration. Sequence Diagrams are time focus and they show the order of the interaction visually by using the vertical axis of the diagram to represent time what messages are sent and when.
Sequence Diagrams captures:
the interaction that takes place in a collaboration that either realizes a use case or an operation (instance diagrams or generic diagrams)
high-level interactions between user of the system and the system, between the system and other systems, or between subsystems (sometimes known as system sequence diagrams)
Purpose of Sequence Diagram
Model high-level interaction between active objects in a system
Model the interaction between object instances within a collaboration that realizes a use case
Model the interaction between objects within a collaboration that realizes an operation
Either model generic interactions (showing all possible paths through the interaction) or specific instances of a interaction (showing just one path through the interaction)
UML序列图是详细说明操作如何进行的交互图。 它们捕获协作上下文中对象之间的交互。 序列图是时间焦点，它们通过使用图的垂直轴来表示发送什么消息和何时发送的时间，直观地显示交互的顺序。
序列图捕获：
在实现用例或操作（实例图或泛型图)的协作中发生的交互）
系统用户与系统之间、系统与其他系统之间或子系统之间的高级交互（有时称为系统序列图）
顺序图的目的
模拟系统中活动对象之间的高级交互
模拟实现用例的协作中对象实例之间的交互
模拟实现操作的协作中对象之间的交互
模型泛型交互（通过交互显示所有可能的路径)或交互的特定实例(通过交互只显示一条路径）
9.3项目联系
顺序图是一种强调对象间消息传递次序的交互图，又称为时序图或序列图。描述了在一个用例或操作的执行过程中对象如何通过消息相互交互，说明了消息如何在对象之间被发送和接收以及发送的顺序。本项目的顺序图如下：

---

10.数据流图(Data Flow Diagram)

10.1参考网站
https://www.wisegeek.com/what-is-a-data-flow-diagram.htm
10.2名词定义
A data flow diagram is a structured display of data moving into and out of an information system. The detail within a data flow diagram varies based upon the level assigned to it. Generally, a high-level diagram has only limited information included within it, whereas a lower-level diagram has much more detailed information. This information is used by a development team to manage the data within an information system.
As a team develops an information system, it creates a data flow diagram to document how information will go in and out of the system. Initially, this information is created at a very high level, with only the information system boundaries included within the diagram. As the team develops more of the functionality of the information system, each of the processes within the system may be included on the data flow diagram. This diagram helps the team determine where data will be stored to support the system.
These diagrams serve an important role, since they document how each process within the system accesses information. External systems may also access the data stored within a given information system. These exchanges across systems are documented so that the analysts may track each system interaction. Such interactions are important pieces of information in each organization’s data management process.
数据流图是数据进出信息系统的结构化显示。 数据流图中的细节根据分配给它的级别而变化。 一般来说，高级图只包含有限的信息，而低级图则包含更详细的信息。 开发团队使用这些信息来管理信息系统中的数据。
当一个团队开发一个信息系统时，它创建一个数据流图来记录信息将如何进出系统。 最初，这些信息是在非常高的级别上创建的，图中只包含信息系统边界。 随着团队开发信息系统的更多功能，系统内的每个进程都可以包含在数据流图中。 此图表帮助团队确定将存储数据以支持系统的位置。
这些图表起着重要的作用，因为它们记录系统中的每个进程如何访问信息。 外部系统也可以访问存储在给定信息系统中的数据。 这些跨系统的交换被记录下来，以便分析人员可以跟踪每个系统的交互。 这种交互是每个组织数据管理过程中的重要信息。
一个数据流图中主要包含下面四种元素
1)数据流：由数据组成，箭头表示数据的流向，每个数据流具有一个名称来反映数据流的含义.
2)加工：描述输入数据流经过什么样的处理变成输出数据流.（相当于程序中的函数）.
3)数据存储(文件、表)：用来表示暂时存储的数据，每个文件都有名字。数据流流向文件表示写文件，数据流流出文件表示读文件.
4)外部实体：存在于软件系统外的人员组织，如操作该软件系统的人就属于外部实体
10.3项目联系
本项目的公司人事管理系统里面的用户登录功能的数据流图，公司员工在系统前端中进行登录，系统根据后端数据库的的数据进行核实还有权限验证，确认用户登陆信息，对该公司员工确认是否登入。数据管理员（即公司人事管理员）在该系统进行权限管理赋予公司层权限以及对公司员工进行用户管理、人事管理等操作。

---

11.中断流（Interrupt Flow）

11.1参考网站
https://sparxsystems.com/enterprise_architect_user_guide/15.1/model_domains/interruptflow.html
11.2名词定义
The Interrupt Flow is a connection used to define the two UML concepts of connectors for Exception Handler and Interruptible Activity Region. An Interrupt Flow is a type of activity edge. It is typically used in an Activity diagram, modeling an active transition…
中断流是用于定义异常处理程序和可中断活动区域的连接器的两个UML概念的连接。中断流是活动边缘的一种类型。它通常用于活动图中，为活动转换建模。
11.3项目联系
在本项目中的中断流只定义在了登录界面，如：当用户在登录信息登陆系统时，前端页面会对输入的数据进行审核，核实后端数据库的数据，进行比较，如果正确进入系统，错误则中断该活动，重新登录。

---

12.状态化分析（Structured Analysis）

---

2.可维护性(Maintainability)

12.1参考网站
https://www.tutorialspoint.com/system_analysis_and_design/system_analysis_and_design_structured.htm
12.2名词定义
Analysts use various tools to understand and describe the information system. One of the ways is using structured analysis.
What is Structured Analysis?
Structured Analysis is a development method that allows the analyst to understand the system and its activities in a logical way.
It is a systematic approach, which uses graphical tools that analyze and refine the objectives of an existing system and develop a new system specification which can be easily understandable by user.
It has following attributes −
It is graphic which specifies the presentation of application.
It divides the processes so that it gives a clear picture of system flow.
It is logical rather than physical i.e., the elements of system do not depend on vendor or hardware.
It is an approach that works from high-level overviews to lower-level details.
分析人员使用各种工具来理解和描述信息系统。方法之一是使用结构化分析。
结构化分析是一种开发方法，它允许分析员以逻辑的方式理解系统及其活动。
它是一种系统化的方法，它使用图形化的工具来分析和细化现有系统的目标，并开发一个用户容易理解的新的系统规范。
它具有以下属性：
它是指定应用程序表示的图形。
它将过程进行了划分，以便对系统流程进行清晰的描述。
它是逻辑的而不是物理的，即系统的元素不依赖于供应商或硬件。
这是一种从高层概述到较低层次细节的方法。

12.3项目联系
在结构化分析过程中，各种工具和技术用于系统开发。它们是：
数据流图、数据字典、决策树、决策表、结构化英语、伪码

本项目在结构化分析过程中使用了数据流图和数据字典等来对系统进行结构化分析，由于系统尚未实现，对其进行需求分析时，其伪码也为进行编写，未能展示出来，数据流图在第10个单词可查阅。

---

13.对象流状态（object flow state）

13.1参考网站
https://www.sparxsystems.com/enterprise_architect_user_guide/14.0/model_domains/objectflow.html
13.2名词定义
Object Flows are used in Activity diagrams and StateMachine diagrams. When used in an Activity diagram, an Object Flow connects two elements, with specific data passing through it, modeling an active transition. To view sample Activity diagrams using Object Flows, see the Object Flows in Activity Diagrams topic.
In StateMachine diagrams, an Object Flow is a specification of a state flow or transition. It implies the passing of an Object instance between elements at run-time.
You can insert an Object Flow from the ‘State’ or ‘Activity’ pages of the Toolbox, or from the drop-down list of all relationships located in the header toolbar. You can also modify a transition connection to an Object Flow by selecting the ‘ObjectFlow’ checkbox on the connection ‘Properties’ dialog.
See the Control Flow topic for information on setting up Guards and Weights on Object Flows.
在活动图和状态机图中使用对象流。 当在Activity图中使用时，Object Flow连接两个元素，并通过它们传递特定的数据，从而建模活动转换。 要使用对象流查看示例活动图， 在状态机图中，对象流是状态流或转换的规范。 它意味着在运行时在元素之间传递对象实例。
您可以从工具箱的“状态”或“激活”页面，或从位于标题工具栏中的所有关系的下拉列表中插入一个对象流。 您还可以通过在连接“属性”对话框中选择“对象流”复选框来修改到对象流的转换连接。
对象流：有的时候，我们可能需要将内存中的对象持久化到硬盘上，或者将硬盘中的对象信息读到内存中，这个时候我们需要使用对象输入输出流。
13.3项目联系
在报告中的单词中，有包括活动图还有状态机图，在该图中有使用对象流连接两个元素，并通过它们传递特定的数据，从而建模活动转换。 在每个时序图和活动图等，每一个箭头都是对象流入或流出的数据，从一个对象的数据流到另一个对象。

---

14.多重继承(multiple inheritance)

14.1参考网站
https://www.geeksforgeeks.org/java-and-multiple-inheritance/
14.2名词定义
Deriving directly from more than one class is usually called multiple inheritance. Since it’s widely believed that this concept complicates the design and debuggers can have a hard time with it, multiple inheritance can be a controversial topic. However, multiple inheritance is an important feature in C++ and C++ programmers think of it as a very good structuring tool.
Class inheritance is a fantastic way to create a class based on another class in order to stay DRY.
多重继承是面向对象概念的一个特性，其中一个类可以继承多个父类的属性。当超类和子类中存在具有相同签名的方法时，就会出现问题。在调用该方法时，编译器无法确定要调用哪个类方法，甚至在调用哪个类方法时将获得优先级。类继承是基于另一个类来创建一个类以保持干燥的极好方法。直接从多个类派生通常称为多重继承。由于人们普遍认为这个概念会使设计复杂化，而且调试器很难使用它，所以多重继承可能是一个有争议的话题。然而，多重继承是C语言的一个重要特性，C程序员认为它是一个非常好的结构化工具。
14.3项目联系
多重继承是代码编写时应用的情况，项目中的需求分析不涉及实现系统。故与项目很难以联系起来。当然在项目实现的阶段，每个项目可能会应用到的部分

---

15.包装图（Package Diagram）

15.1参考网站
https://blog.csdn.net/kimylrong/article/details/40043389
15.2名词定义
Package diagram, a kind of structural diagram, shows the arrangement and organization of model elements in middle to large scale project. Package diagram can show both structure and dependencies between sub-systems or modules, showing different views of a system, for example, as multi-layered (aka multi-tiered) application - multi-layered application model.
什么是Package
用最简单的方式来说，Package可以理解为文件夹(folder)。代码的组织从大到小，分为三个层次:文件夹层，文件层，以及文件内部的块(Block)层(函数块之类的)。Package体现的就是文件夹层。Java里面可能是一串文件夹，比如java.lang、java.util等，也叫Package；C++里面，Package对应的是namespace，虽然不能完全等同于文件夹，不过也可以往这边靠；其它的如Node.js，Python等大都体现在文件夹层。
Package在UML里面用一个Tab框表示，Tab里面写上Package的名字，框里面可选地填充一些其它子元素，如类，子Package等。Package的名字可以写全称，也可以简写，风格可可参考项目所用语言的惯例。
如果只有一个Package，那也就失去了Package的作用，没有画Package Diagram的意义。Package之间的关系非常的简单，两个字，依赖，UML中依赖用带箭头的虚线表示。我个人还是非常不建议依赖关系出现Cycle的。依赖关系最常见的一个例子就是分层架构，把代码分布到多个层次中，某层可以依赖于下层以及同层，但是不能依赖于上层。其它的组织方式还包括按照模块划分，按照功能划分等。
15.3项目联系
Package Diagram从宏观角度展示了项目的组织架构，在大型项目中，Package Diagram是重要的一种UML图。可以先Package Diagram，再Class Diagram的方式来展示项目的架构。以下本项目的Package Diagram，根本在网上学习的资料参考画的。

---

16.形式参数（formal parameter）

16.1参考网站
https://www.differencebetween.com/difference-between-actual-and-vs-formal-parameters/
16.2名词定义
What are Formal Parameters?
A function or a method follows a syntax similar to those given below:
(formal parameters) {
//set of statements to be executed
}
The method name is to identify the method. The return type specifies the type of the value the method will return. If the method does not return a value, the return type is void. If the function is returning an integer value, then the return type is an integer. The formal parameter list is enclosed in parenthesis. The list contains variable names and data types of all the necessary values for the method. Each formal parameter is separated by a comma. When the method is not accepting any input values, then the method should have an empty set of parentheses after the method name. e.g. addition () { }; The statements that should be executed are enclosed in curly braces.
方法名用于标识方法。返回类型指定方法将返回的值的类型。如果方法不返回值，则返回类型为void。如果函数返回整数值，则返回类型为整数。形式参数列表用括号括起来。包含所需的变量名称和方法值列表。每个形式参数用逗号隔开。当方法不接受任何输入值时，方法名称后面应该有一组空括号。e、 addition（）{}；应该执行的语句用大括号括起来。
形式参数是由函数定义的变量，该函数在调用函数时接收值。根据上述程序，值2和3传递给函数加法。在加法函数中，有两个变量称为x和y。值2被复制到变量x中，值3被复制到变量y中。变量x和y不是实际参数。它们是实际参数的副本。它们被称为形式参数。这些变量只能在方法中访问。打印两个数字的加法后，控件返回主程序。
形式参数是函数定义的变量，函数在调用函数时接收值。
16.3项目联系
形式参数是代码编写时应用的情况，项目中的需求分析不涉及实现系统。故与项目很难以联系起来。当然在项目实现的阶段，每个项目都会应用到的部分

---

17.元元模型（meta-metamodel）

17.1参考网站
https://cs.wmich.edu/~ooda/metamodel.html
17.2名词定义
Metamodelingis the name commonly given to the practice of using a model to describe another model as an instance. One feature of metamodeling is that it must be possible to assign properties to classes in the model.
The individual concepts in the metamodel are described bymetaclassesthat are related to each other using generalizations and associations in a similar fashion to the way blocks can be related to one another on ablock definition diagram. Each metaclass has a description and a set of properties that characterize the concept it represents, and also a set of constraints that impose rules on those properties’ values.
元模型是在感兴趣的领域中构建特定模型所需的构造和规则的显式模型，它是最终的模型，但控制着如何对感兴趣的系统或领域进行建模。让我们在下一节中探讨一些定义和示例。
Metamodeling是一个常用的名称，用于将一个模型描述为实例的另一个模型。元建模的一个特点是必须能够将属性分配给模型中的类。这种做法在owl1.0中造成了一个问题，因为owl1.0不允许以这种方式将类视为个体。
元建模的一个动机是模型通常需要在一个应用程序中扮演多个角色：一个特定的概念应该被视为一个角色中的一个类，但在另一个角色中被视为一个实例。
元模型中的各个概念由metaclasses使用泛化和关联相互关联，其方式类似于在方块定义图. 每个元类都有一个描述和一组属性，这些属性描述了它所表示的概念，还有一组约束对这些属性的值施加规则。
17.3项目联系
元模型定义了描述某一模型的规范，具体来说就是组成模型的元素和元素之间的关系。元模型是相对与模型的概念,离开了模型元模型就没有了意义。在本系统中，公司人事管理系统里面有管理系统还有请假系统，当着两个系统离开的公司人事管理系统，其本身就不知道代表什么管理什么请假什么，就没有了意义。

---

18.动态模型（dynamic model）

---

2.可维护性(Maintainability)

18.1参考网站
https://sparxsystems.com/resources/tutorials/uml/dynamic-model.html
18.2名词定义
The dynamic model is used to express and model the behaviour of the system over time. It includes support for activity diagrams, state diagrams, sequence diagrams and extensions includingbusiness process modelling.
动态模型用于表示和建模系统随时间的行为。它包括对活动图、状态图、序列图和扩展的支持，包括业务流程建模
序列图
序列图用于显示系统内用户、屏幕、对象和实体之间的交互。它提供了一个随时间在对象之间传递消息的顺序映射。通常，这些图被放在模型中的用例下，以说明用例场景——用户将如何与系统交互，以及如何在内部完成工作。通常，对象是用特殊的构造型图标来表示的，如下面的示例所示。标记为登录屏幕的对象使用用户界面图标显示。标记为SecurityManager的对象使用控制器图标显示。标记为“用户”的对象将使用实体图标显示。
行为图
活动图用于显示系统中不同的工作流是如何构建的，它们是如何开始的，以及从开始到结束可能有许多决策路径。它们还可以说明在执行某些活动时可能发生并行处理的位置。
状态图
状态图用于详细说明对象在系统中可以经历的状态转换或更改。它们显示了对象如何从一个状态移动到另一个状态，以及控制这种变化的规则。状态图通常有一个开始和结束条件。
过程模型
流程模型是用于对业务流程建模的活动图的UML扩展，该图显示了流程的目标、流程中涉及的输入、输出、事件和信息。
18.3项目联系
动态模型中，我们建立了有序列图、状态图还有过程模型，在这里中序列图和状态图都在本报告中都有展示，可以在本报告中查看，这里展示的时过程模型，描述我们项目某个功能的流程，显示了流程的目标、流程中涉及的输入、输出、事件和信息。登记员工用户信息的流程如下，未展示的还有下面的后端流程。

---

19.基本业务流程（Basic Business Process）

19.1参考网站
https://www.sciencedirect.com/topics/computer-science/business-process-diagram
19.2名词定义
What Is BPMN?
Business Process Model and Notation (BPMN) is a standard for business process modeling that provides graphical notation for specifying business processes in a Business Process Diagram (BPD),2 based on traditional flowcharting techniques. The objective of BPMN is to support business process modeling for both technical users and business users, by providing notation that is intuitive to business users, yet able to represent complex process semantics.
业务流程模型和符号(BPMN)是业务流程建模的标准，它提供了基于传统流程图技术在业务流程图2中指定业务流程的图形表示法。 BPMN的目标是支持技术用户和业务用户的业务流程建模，为业务用户提供直观的符号，但能够表示复杂的流程语义。
描述活动、网关、事件、工件、池和通道的定义、符号和语法。 业务流程建模符号(BPMN)的定义、符号和语法)。 当前用于业务流程建模的符号包括三个主要符号：EPC（事件驱动流程链）、UML（统一建模语言）以及最近的BPMN（业务流程建模符号）。提供一个标准化的图形化表示法，以便所有利益相关者都能理解这个表示法，从业务分析师到流程实现者；该表示法还可以映射到基于XML的可执行流程语言
19.3项目联系
公司中管理员登录公司员工的业务流程图，在现实中则是员工进入公司的整个业务流程。

---

20.静态类（static classification）

20.1参考网站
https://docs.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/dev-ref/xpp-static-classes
20.2名词定义
Static Class
A static class cannot be instantiated. All members of a static class are static and are accessed via the class name directly, without creating an instance of the class.
This topic describes static class members in X++. In general, static methods are intended for these cases:
The method has no reason to access the member variables that are declared in the class.
The method has no reason to call any instance (non-static) methods of the class.
You declare static class members by using thestatickeyword. Thestatickeyword instructs the system to create only one instance of the method, regardless of the number of instances of the class there are. This one instance is used throughout your session.
Static methods
This section describes a scenario where a software key type is used to help prevent piracy. Each instance of a software key can have its own unique value. Because all software keys must conform to the rules of software key design, the logic that tests for software key conformance is the same for all software keys. Therefore, the method that contains the conformance validation logic should be static.
静态类
不能实例化静态类。 静态类的所有成员都是静态的，并且通过类名直接访问，而不创建类的实例。
静态类包含两种类型的静态成员，如下所示：
静态数据成员：由于静态类总是包含静态数据成员，所以静态数据成员是使用static关键字声明的，并且通过类名直接访问它们。静态数据成员的内存是单独分配的，与对象没有任何关系。
静态方法
由于静态类总是包含静态方法，所以静态方法是使用static关键字声明的。这些方法只访问静态数据成员，不能访问非静态数据成员。描述一个场景，其中使用软件密钥类型来帮助防止盗版。 软件密钥的每个实例都有其独特的价值。 由于所有软件密钥都必须符合软件密钥设计的规则，所以测试软件密钥一致性的逻辑对于所有软件密钥都是相同的。 因此，包含一致性验证逻辑的方法应该是静态的。
20.3项目联系
静态类是代码编写时应用的情况，项目中的需求分析不涉及实现系统。故与项目很难以联系起来。当然在项目实现的阶段，每个项目可能会应用到的部分

---

21.单继承（single inheritance）

21.1参考网站
https://blog.csdn.net/qcyfred/article/details/53440534
https://www.techopedia.com/definition/22104/single-inheritance
22.2名词定义
Single Inheritance
Single inheritanceis the simplest of the inheritance models. This is used when you have a class that has basic characteristics and you need to create more classes that have all the basic characteristics and some specific characteristics.
单身继承
单继承是最简单的继承模型。 这是在您有一个具有基本特性的类并且需要创建更多具有所有基本特性和某些特定特性的类时使用的。
单一继承使派生类能够从单个父类继承属性和行为。它允许派生类继承基类的属性和行为，从而实现代码的可重用性以及向现有代码添加新功能。这使得代码更加优雅，重复性更少。继承是面向对象编程（OOP）的关键特性之一。
如果以正确的方式处理单一继承比多重继承更安全。如果派生类或父类构造函数中重写了某个特定方法的父类实现，则它还允许派生类调用该方法的父类实现。
23.3项目联系
与上面的多继承进行对比，正如我查阅的资料所说，如果以正确的方式处理单一继承比多重继承更安全。如果派生类或父类构造函数中重写了某个特定方法的父类实现，则它还允许派生类调用该方法的父类实现。在本项目的实现过程中，若可以正确的方式处理单一继承，会不用多重继承，使系统更加安全。

---

22.验收测试（acceptance test）

22.1参考网站
https://softwaretestingfundamentals.com/acceptance-testing/
22.2名词定义
ACCEPTANCE TESTING is a level of software testing where a system is tested for acceptability. The purpose of this test is to evaluate the system’s compliance with the business requirements and assess whether it is acceptable for delivery (or writing that big check).
ISTQB Definition
acceptance testing:Formal testing with respect to user needs, requirements, and business processes conducted to determine whether or not a system satisfies the acceptance criteria and to enable the user, customers or other authorized entity to determine whether or not to accept the system.
验收试验是软件测试的一个级别，其中测试系统的可接受性。此测试的目的是评估系统对业务需求的符合性，并评估它是否可以交付（或编写大支票）。
一旦系统测试过程由测试团队完成并签署后，将整个产品/应用程序移交给客户/客户的少数用户/两者，以测试其可接受性，即产品/应用程序在满足关键和主要业务要求方面应完美无缺。此外，端到端业务流的验证与实时场景中的类似。类似生产的环境将是接受测试的测试环境（通常称为分段、预生产、故障转移、UAT环境）。
ISTQB定义
验收测试：与用户需求、需求和业务流程有关的正式测试，以确定系统是否满足验收标准，并使用户、客户或其他授权实体能够确定是否接受该系统。
验收测试有多种形式：
用户验收测试、业务验收测试、阿尔法测试、β测试
22.3项目联系
在开发完成后的阶段，系统将会进行测试，对功能继续测试，对整个系统的性能进行测试，看他是否能够上市，是否基本满足客户的需求，能否正常的工作，对测试出现的bug进行改正，最后进行汇报，重复的测试以获得对即将投放市场的产品的信心。以确保产品按其必须的方式工作。确保产品符合当前市场标准，并与市场上其他同类产品具有足够的竞争力。

---

23.初始节点（initial node ）

23.1参考网站
https://www.uml-diagrams.org/activity-diagrams-controls.html
23.2名词定义
Initial node is a control node at which flow starts when the activity is invoked.
A control token is placed at the initial node when the activity starts, but not in initial nodes in structured nodes contained by the activity. Tokens in an initial node are offered to all outgoing edges. For convenience, initial nodes are an exception to the rule that control nodes cannot hold tokens if they are blocked from moving downstream, for example, by guards.
初始节点显示为一个小的实心圆。
活动可以有多个初始节点。在本例中，调用活动将启动多个流，每个流在每个初始节点上。
初始节点是当活动被调用时流开始的控制节点。
当活动开始时，控制令牌被放置在初始节点，而不是在活动包含的结构化节点中的初始节点中。 初始节点中的令牌提供给所有输出边缘。 为了方便起见，初始节点是规则的一个例外，即如果控制节点被阻止向下游移动，
23.3项目联系
在活动图等图表中，展示在本报告中，公司用户员工入职阶段的初始阶段到终点阶段，在状态图描述员工这个初始节点的状态。

---

24.应用程序域（Application domain）

24.1参考网站
https://docs.microsoft.com/en-us/dotnet/framework/app-domains/application-domains
24.2名词定义
Application domains
Operating systems and runtime environments typically provide some form of isolation between applications. For example, Windows uses processes to isolate applications. This isolation is necessary to ensure that code running in one application cannot adversely affect other, unrelated applications.
Application domains provide an isolation boundary for security, reliability, and versioning, and for unloading assemblies. Application domains are typically created by runtime hosts, which are responsible for bootstrapping the common language runtime before an application is run.
操作系统和运行时环境通常在应用程序之间提供某种形式的隔离。例如，Windows使用进程来隔离应用程序。为了确保在一个应用程序中运行的代码不会对其他不相关的应用程序产生负面影响，必须进行这种隔离。
应用程序域为安全性、可靠性和版本控制以及卸载程序集提供了隔离边界。应用程序域通常由运行时主机创建，运行时主机负责在应用程序运行前引导公共语言运行时。
应用程序域提供了一种灵活、安全的隔离应用程序的方法。
应用程序域通常由运行时主机创建和操作。有时，您可能希望应用程序与应用程序域进行编程交互，例如，在不停止应用程序运行的情况下卸载组件。
应用程序域有助于安全性，将应用程序与其他应用程序以及彼此的数据分开。一个进程可以运行多个应用程序域，其隔离级别与独立进程中的隔离级别相同。在单个进程中运行多个应用程序可提高服务器的可扩展性。
24.3项目联系
在员工入职登录时，人事管理员进行员工登录，运用该功能时，系统会出现一下应用程序，对员工信息进行登录，当登录多名员工信息时，可以运行多个应用程序域，将应用程序与其他应用程序以及彼此的数据分开。提高服务器的可扩展性。

---

25.领域模型（Domain Model）

25.1参考网站
https://www.wisdomjobs.com/e-university/uml-tutorial-175/what-is-a-domain-model-13285.html
25.2名词定义
A domain model is a visual representation of conceptual classes or real - situation objects in a domain [M095, Fowler96]. Domain models have also been called conceptual models(the term used in the first edition of this book),domain object models,and analysis object models.
领域模型是领域内的概念类或现实世界中对象的可视化表示，又称为概念模型或分析对象模型，它专注于分析问题领域本身，发掘重要的业务领域概念，并建立业务领域概念之间的关系。
贫血模型是指使用的领域对象中只有setter和getter方法（POJO），所有的业务逻辑都不包含在领域对象中而是放在业务逻辑层。有人将我们这里说的贫血模型进一步划分成失血模型（领域对象完全没有业务逻辑）和贫血模型（领域对象有少量的业务逻辑），我们这里就不对此加以区分了。
充血模型将大多数业务逻辑和持久化放在领域对象中，业务逻辑（业务门面）只是完成对业务逻辑的封装、事务和权限等的处理。下面两张图分别展示了贫血模型和充血模型的分层架构
25.3项目联系
下图是本项目设计的domain model，在学习该模型过程中，不是很了解该模型。

---

26.持久对象（persistent object）

26.1参考网站
https://help.hcltechsw.com/commerce/8.0.0/developer/concepts/csdpersistentobjectmodel.html
26.2名词定义
Persistent object model
WebSphere Commercedeals with a large amount of persistent data.There are numerous tables defined in the current database schema. Even withthis extensive schema, however, you might need to extend or customize thedatabase schema for your particular business needs.
WebSphere Commerceuses entity beans that are based on the EnterpriseJavaBeans (EJB) Version 2.1 component architecture as the persistent objectlayer. Most of theWebSphere Commerceentity beans are at EJB 1.1 level. Allthe EJB modules insideWebSphere Commerceare at EJB 2.x level. These entitybeans representWebSphere Commercedata in a manner that models concepts andobjects in the commerce domain. This persistence layer provides an extensibleframework.
持久对象模型
WebSphere商务处理大量的持久性数据。在当前的数据库模式中定义了许多表。但是，即使使用这种扩展的模式，您也可能需要扩展或自定义数据库模式以满足您的特定业务需求。
WebSphere商务使用基于EnterpriseJavaBeans（EJB）2.1版组件体系结构的实体bean作为持久对象层。大部分WebSphere商务实体bean位于EJB1.1级别。所有的EJB模块都在里面WebSphere商务在EJB2.x级别。这些EntityBean代表WebSphere商务以商业领域中的概念和对象为模型的数据。这个持久层提供了一个可扩展的框架。
最形象的理解就是一个PO就是数据库中的一条记录。好处是可以把一条记录作为一个对象处理，可以方便的转为其它对象。PO是由一组属性和属性的get和set方法组成。
26.3项目联系
对于持久对象的了解还不够深刻，本项目的持久对象很难以分析，持久对象（persistent object）是2018年公布的计算机科学技术名词。

---

27.用例模型（use case model）

27.1参考网站
https://www.gatherspace.com/what-is-a-use-case-model/
27.2名词定义
What is a Use Case Model
The Use Case Model is used to define the core elements and processes that makeup a system. The key elements are termed as “actors” and the processes are called “use cases.” The Use Case Model shows which actors interact with each use case. This definition defines what a Use Case Model is primarily made up of—actors and use cases.
A Use Case Model should capture the functional system components. It embosses the business processes within the system. While you traverse your system, you will learn significant system attributes that you model in the Use Case Model. Because Use Case Models are simple in nature, they are free of technical jargon, Use Case Models are a great way to storyboard flows with users. Use Case Models have another critical role. Use Case Models define the system requirements being modeled and help write the scenarios later used in testing.
UML Use Case Models can be used to describe the functionality of a system in a horizontal way. That is, rather than merely representing the details of individual features of your system, Use Case Models can be used to show all of its available functionality. It is important to note, though, that Use Case Models are fundamentally different from sequence diagrams or flow charts because they do not make any attempt to represent the order or number of times that the systems actions and sub-actions should be executed. There are a number of graphical examples in this FAQ; you might want to look over them to familiarize yourself with the look of them.
Use Case Models have only 4 major elements: The actors that the system you are describing interacts with, the system itself, the use cases, or services, that the system knows how to perform, and the lines that represent relationships between these elements.
You should use Use Case Models to represent the functionality of your system from a top-down perspective (that is, at a glance the system’s functionality is obvious, but all descriptions are at a very high level. Further detail can later be added to the diagram to elucidate interesting points in the system’s behavior.)
用例模型用于定义组成系统的核心元素和过程。关键元素被称为“参与者”，过程被称为“用例”。用例模型显示了哪些参与者与每个用例交互。这个定义定义了用例模型主要由参与者和用例组成。
用例模型描述了新系统的建议功能。用例表示用户（人或机器）和系统之间交互的离散单元。此交互是一个有意义的工作单元，例如创建帐户或查看帐户详细信息。
用例模型应该捕获功能系统组件。它凸显出系统内的业务流程。当您遍历系统时，您将了解在用例模型中建模的重要系统属性。因为用例模型本质上很简单，它们不受技术术语的约束，所以用例模型是一种很好的与用户进行故事板流的方式。用例模型还有另一个关键角色。用例模型定义被建模的系统需求，并帮助编写稍后在测试中使用的场景。
UML用例模型可以用来水平地描述系统的功能。也就是说，用例模型不仅可以表示系统的各个特性的细节，还可以用来显示它的所有可用功能。但是需要注意的是，用例模型与序列图或流程图有着根本的不同，因为它们不试图表示系统动作和子动作应该执行的顺序或次数。在这个常见问题解答中有许多图形示例；您可能需要仔细查看这些示例以熟悉它们的外观。
每个用例描述了要在提议的系统中构建的功能，它可以包括另一个用例的功能，或者用它自己的行为扩展另一个用例。
用例模型只有4个主要元素：您描述的系统与之交互的参与者、系统本身、用例或系统知道如何执行的服务，以及表示这些元素之间关系的行。
您应该使用用例模型从自顶向下的角度来表示系统的功能（也就是说，一眼望去，系统的功能是显而易见的，但是所有的描述都是在一个非常高的层次上。以后可以在图表中添加更多细节，以阐明系统行为中的有趣点。）
27.3项目联系
这里展示了两个actor在本系统的使用和用例，公司老板的actor相当于内嵌的管理员，所以在这里的用例模型就不展示公司老板这个actor，管理员的功能是建立在公司老板的基础上，甚至比公司老板更高级，权限更高，相当于开发者、数据库管理员。该视图简单的展示了部分功能。

---

28.交互图(interaction diagram)

28.1参考网站
https://www.javatpoint.com/uml-interaction-diagram
28.2名词定义
UML Interaction Diagram
As the name suggests, the interaction diagram portrays the interactions between distinct entities present in the model. It amalgamates both the activity and sequence diagrams. The communication is nothing but units of the behavior of a classifier that provides context for interactions.
A set of messages that are interchanged between the entities to achieve certain specified tasks in the system is termed as interaction. It may incorporate any feature of the classifier of which it has access. In the interaction diagram, the critical component is the messages and the lifeline.
In UML, the interaction overview diagram initiates the interaction between the objects utilizing message passing. While drawing an interaction diagram, the entire focus is to represent the relationship among different objects which are available within the system boundary and the message exchanged by them to communicate with each other.
The message exchanged among objects is either to pass some information or to request some information. And based on the information, the interaction diagram is categorized into the sequence diagram, collaboration diagram, and timing diagram.
The sequence diagram envisions the order of the flow of messages inside the system by depicting the communication between two lifelines, just like a time-ordered sequence of events.
The collaboration diagram, which is also known as the communication diagram, represents how lifelines connect within the system, whereas the timing diagram focuses on that instant when a message is passed from one element to the other.
顾名思义，交互图描述了模型中不同实体之间的交互。它合并了活动图和序列图。通信只是为交互提供上下文的分类器的行为单元。
一组在实体之间交换以实现系统中某些特定任务的消息称为交互。它可以包含它可以访问的分类器的任何特性。在交互图中，关键组件是消息和生命线。
在UML中，交互概述图利用消息传递启动对象之间的交互。在绘制交互图时，整个工作重点是表示系统边界内可用的不同对象之间的关系，以及它们之间为了相互通信而交换的消息。
对象之间交换的消息要么传递一些信息，要么请求一些信息。根据这些信息，将交互图分为序列图、协作图和时序图。
序列图通过描述两条生命线之间的通信来设想系统内消息流的顺序，就像按时间顺序排列的事件序列。
协作图，也称为通信图，表示系统中生命线的连接方式，而时序图则侧重于消息从一个元素传递到另一个元素的那一瞬间。
交互图有助于设想任何系统的交互（动态）行为。它描述了驻留在系统中的对象如何相互通信和连接。它还为我们提供了系统内部生命线之间的通信上下文。
以下是交互图的目的：
一．可视化系统的动态行为。
二．设想系统中的交互和消息流。
三．描绘系统内实体的结构方面。
四．表示系统中顺序交互的顺序。
五．可视化实时数据并表示面向对象系统的体系结构。
交互图可用于：
序列图被用来研究一个新的应用。
交互图探索并比较了协作图序列图和时序图的使用。
交互图表示系统的交互（动态）行为。
序列图描述了控制流从一个元素到系统内其他元素的顺序，而协作图则用于获得系统对象体系结构的概述。
交互图将系统建模为系统的时序序列。
交互图将系统建模为系统的时序序列。
交互图系统化了交互元素的结构。
28.3项目联系
本项目的功能系统的交互（动态）行为，控制流从一个元素到系统内其他元素的顺序，描述了驻留在系统中的功能如何调用其他功能还有对数据库的管理。如图以下只是部分功能的交互图。

---

29.状态机或状态图(state machine)

29.1参考网站
https://www.lucidchart.com/pages/uml-state-machine-diagram
29.2名词定义
What is a state diagram in UML?
A state diagram, sometimes known as a state machine diagram, is a type of behavioral diagram in the Unified Modeling Language (UML) that shows transitions between various objects.
What is a state diagram in UML?
A state machine is any device that stores the status of an object at a given time and can change status or cause other actions based on the input it receives. States refer to the different combinations of information that an object can hold, not how the object behaves. In order to understand the different states of an object, you might want to visualize all of the possible states and show how an object gets to each state, and you can do so with a UML state diagram.
Each state diagram typically begins with a dark circle that indicates the initial state and ends with a bordered circle that denotes the final state. However, despite having clear start and end points, state diagrams are not necessarily the best tool for capturing an overall progression of events. Rather, they illustrate specific kinds of behavior—in particular, shifts from one state to another.
State diagrams mainly depict states and transitions. States are represented with rectangles with rounded corners that are labeled with the name of the state. Transitions are marked with arrows that flow from one state to another, showing how the states change. Below, you can see both these elements at work in a basic diagram for student life.
State diagram applications
Like most UML diagrams, state diagrams have several uses. The main applications are as follows:
Depicting event-driven objects in a reactive system.
Illustrating use case scenarios in a business context.
Describing how an object moves through various states within its lifetime.
Showing the overall behavior of a state machine or the behavior of a related set of state machines.
状态图，有时称为状态机图，是统一建模语言（UML）中的一种行为图，它显示了不同对象之间的转换。
状态图为我们提供了一种有效的方法来建模外部实体和系统中发生的交互或通信。这些图用于对基于事件的系统进行建模。对象的状态是通过事件来控制的。
状态机是存储对象在给定时间的状态的任何设备，它可以根据接收到的输入更改状态或引起其他操作。状态是指一个对象可以保存的信息的不同组合，而不是对象的行为方式。为了理解一个对象的不同状态，您可能希望可视化所有可能的状态，并展示对象如何到达每个状态，您可以使用UML状态图来实现这一点。
每个状态图通常以一个表示初始状态的黑圈开始，以表示最终状态的带边框圆圈结束。然而，尽管有明确的起点和终点，状态图并不一定是捕捉事件整体进展的最佳工具。相反，它们特别说明了从一种状态到另一种状态的特定行为。
状态图主要描述状态和转换。状态用带有圆角的矩形表示，这些矩形标有状态的名称。转换用箭头标记，箭头从一个状态流向另一个状态，显示状态如何变化。下面，你可以在学生生活的基本图表中看到这两个元素在起作用。
状态图应用程序
与大多数UML图一样，状态图有多种用途。主要应用如下：
描述反应系统中事件驱动的对象。
说明业务上下文中的用例场景。
描述一个对象如何在其生命周期内经历各种状态。
显示一个状态机的整体行为或一组相关的状态机的行为。
29.3项目联系
本项目在员工入职期间的状态进行描绘，在本系统中，对人事资源的管理进行输入输出，在一名员工入职期间，管理员录入该员工的信息（即状态试用工、基本信息等），在该名员工的试用期观察，对这名员工进行审核考察，查看他是否符合我们的公司的人才需要，试用期结束后，若考核成功，由该员工自己决定去留，留则需要上级批准是否能够成为公司的正式员工。失败则公司将淘汰该员工。这就是本项目员工入职的状态图。

---

30.非功能性需求(non-functional requirement)

30.1参考网站
https://www.plutora.com/blog/non-functional-requirements-guide
https://www.altexsoft.com/blog/non-functional-requirements/
30.2名词定义
What Are Non-Functional Requirements?
Every requirement that is not functional is a non-functional requirement. Non-functional requirements are different from functional requirements insofar as they do not affect the basic functions of a system. If they are excluded, the system will still function on a basic level. Now you may ask, why are these requirements necessary? Their value comes from a better usability. Non-functional requirements describe how efficiently a system should function. They refer to the general qualities that provide a good user experience. And they improve the quality of performance, accuracy, maintenance, auditing, security, error-handling, reliability, scalability, usability, and capacity.
We can further classify non-functional-requirements as operational, revision, and transition requirements.
Operational Requirements
Operational requirements describe how well the system is performing. When we refer to operational requirements within non-functional requirements, we are talking about accessibility, confidentiality, integrity, safety, usability, security, availability, efficiency, reliability, and suitability.
Revision Requirements
Revision requirements define how quickly a system solves problems caused by unexpected errors and how efficiently high-priority features can bounce back.
Maintainability, scalability, flexibility, verifiability, and modifiability are classified as revision requirements.
Transition Requirements
Transition requirements define the capacity of the system to accept its surrounding environment. The users who are involved in the management of a system are most likely to be concerned about them.
These requirements include good reusability, installability, portability, and interoperability.
功能需求定义了一个系统应该做什么，而非功能需求描述了一个系统应该如何有效地运行。非功能性需求和功能性需求同样重要。准确地识别和定义这些需求对于确保您的软件在提供良好的用户体验的同时平稳运行非常重要。避免非功能性需求会导致可能导致产品失败的关键问题。
每个不起作用的需求都是非功能性需求。非功能需求不同于功能需求，因为它们不会影响系统的基本功能。如果排除它们，系统仍将在基本级别上运行。现在你可能会问，为什么这些要求是必要的？它们的价值来自于更好的可用性。非功能需求描述了一个系统应该如何有效地运行。它们指的是提供良好用户体验的一般特性。它们提高了性能、准确性、维护、审计、安全性、错误处理、可靠性、可伸缩性、可用性和容量的质量。
我们可以进一步将非功能需求划分为操作需求、修订需求和过渡需求。
操作需求
操作需求描述了系统的性能。当我们提到非功能性需求中的操作需求时，我们指的是可访问性、机密性、完整性、安全性、可用性、安全性、可用性、效率、可靠性和适用性。
修订需求
修订需求定义了系统解决由意外错误引起的问题的速度，以及高优先级功能恢复的效率。
可维护性、可扩展性、灵活性、可验证性和可修改性被分类为修订需求。
过渡需求
过渡需求定义了系统接受周围环境的能力。参与系统管理的用户最有可能关心他们。
这些需求包括良好的可重用性、可安装性、可移植性和互操作性。
30.3项目联系
查找和定义非功能性需求可能会令人困惑，尽管您可以通过分析用户的需求来找到其中的一些需求。无论你做什么，永远不要把它们排除在你的产品之外。你可以创建一些功能足够好的东西，但是如果它需要30秒的时间来加载，而不是完美地工作，它将创建一个糟糕的用户体验，将有效地使它无法使用。
我们项目在用户的需求上定义了他们的功能性需求，但是是这个项目中不仅仅只要有功能性需求怎么简单。
用户 功能
管理员 管理员权限登录系统、管理事务、录入员工初始信息等属性
员工 用户权限登录该系统、查询和修改自己的员工资料、查询工资信息、系统中请假、休假等
老板 修改相关信息（薪资）、查看考勤和病休假等
除了以上的功能性需求，我们还定义了表单打印、用户登录信息修改等非功能性需求。
在查询表格的基础上，在数据表中建立索引，提高表的查询速度，减少系统加载的反映时间，信息系统中保证性能、系统可靠性、可扩展性要求等方面相应的需求要素。分析人员根据实际业务需要进行调研归纳。

---

31.总结

31.1读书心得
每一个单词虽然由几个词语组成，很容易记得起来，但是这几个词语的单词组成的具有很大的内容，每个词语的含义都可以扩展出其他的单词，每个单词都可以联系起来。对学习有很大的作用。
31.2发展建议
在系统需求不同的情况下，做出了的系统的功能也不同，但拓展的功能有相似的，可以在原来的基础上，加入一些特有的元素。
一款好的企业APP软件必定拥有独特的个性化元素，开发者在为企业app开发定制方案的时候，将企业的结合到应用之中，增强其商业价值。如在为从事蛋糕制作企业定制方案的时候，可以开辟一个供用户自行搭配的平台，用户可以通过自身意愿进行款式选择、颜色搭配、口味设置等进行定制心仪蛋糕，进而有效促进消费。
一切应该开发都是为了迎合用户的喜爱，所以在进行定制开发方案的时候，开发者应该从用户的生活细节出发，挖掘符合产品特点的内容进行广告植入。比如星巴克的Early Bird，从用户的生活细节入手进行开发，其中闹钟的功能符合了用户起床必备，同时结合产品的特点进行设置，用户只需要按时起床就可以从中获得福利，受到了用户的广泛欢迎。
为了增强用户的体验感，很多开发者在开发的过程中，在体验功能中添加了游戏互动的元素。在推出的应用中，用户通过下载该应用就可以按照自己喜爱的模式进行自定义家居布局，并且还可以对自己的创意进行分享，参与到票选的比赛中，增强了用户的参与感。
总之，在自身的核心功能中实现自己的个性化，突出自己的核心功能，从而体现出系统的功能性，我们系统要体先出自己的核心功能时，要具备独特的个性化元素，在相同的系统中体现出自己的价值。

---

A002-186-2619-林斌锐相关推荐

1. 小米集团：副董事长林斌承诺5年内不出售公司股份 已作安排的除外

   今日早间,小米集团发布公告称,公司副董事长.执行董事林斌自愿承诺,自本公告日期起五年内,林斌及其控制的所有实体均不会自行酌情出售其直接或间接实益拥有的本公司股份,此前已作安排的不超过1.2亿股B类股除 ...

2. 林斌减持小米股份三天套现3.4亿引关注 小米官方、林斌齐回应...

   小米本月公布财报后,港交所披露消息显示小米总裁林斌在8月21日以9.0731港元卖出2670万股公司股票,8月22日卖出555.96万股,8月23日卖出904.76万股,三日共计卖出4130.72万股 ...

3. 林斌首曝红米骁龙855旗舰新机：3200万像素弹出式前置摄像头

   [TechWeb]近期,关于红米骁龙855旗舰的消息越来越多,虽然官方至今没有关于该机的明确信息,但也正因如此,该机吸引了更多用户的好奇心.现在有最新消息,近日,小米总裁林斌晒出了一整自拍图,出镜的除 ...

4. 小米回应林斌退休传闻；哈工大等高校被禁止使用 MATLAB；统信软件 UOS20 SP1 系统升级| 极客头条...

   整理 | 屠敏 头图 | CSDN 下载自视觉中国 快来收听极客头条音频版吧,智能播报由出门问问「魔音工坊」提供技术支持. 「极客头条」-- 技术人员的新闻圈! CSDN 的读者朋友们早上好哇,「极客 ...

5. 林斌宣布好消息！语音识别大佬、Kaldi之父加盟小米

   [天极网IT新闻频道]10月19日消息,日前,国际语音识别大牛.前约翰霍普金斯大学(Jonhs Hopkins University)教授. 语音识别开源工具Kaldi之父Daniel Povey在T ...

6. 『phphot』【SD2.0大会】Google中国工程研究院副院长林斌演讲

   原文链接:http://blog.csdn.net/phphot/archive/2007/11/30/1908915.aspx 作者:phphot(phphot) http://blog.csdn. ...

7. AI一分钟 | 苹果9月13日凌晨召开发布会；林斌晒小米手机新品，“撞脸”荣耀Magic 2...

   ▌苹果发布会确定:北京时间 9月 13 日凌晨 1 点  8 月 31 日凌晨,苹果官方正式宣布,将于北京时间 9 月 13 日凌晨 1 点(美国当地时间 9 月 12 日上午 10 点)举办 A ...

8. Google中国工程研究院副院长林斌演讲

   2007.11.29  来自:CSDN      共有评论( 0)条 发表评论   [ 收藏到我的网摘] 今天非常荣幸的是, 不仅是我们现场的朋友可以感受到这次大会的盛况,由于有了新浪网以及CSDN网 ...

9. 红米note5有没有人脸识别_官方再曝红米Note 5新特性——AI人脸识别 林斌：看一眼就解锁...

   虽然红米Note 5系列新机早已在印度正式发布,并参展了MWC2018,但是似乎小米对于该机国行版的发布仍然不遗余力,自从官方公布了红米Note 5国行版的正式发布时间后,近段时间,无论是小米官方还是 ...

10. 林大锐格-算法-6121

    //这道题的问题表述应该略有些问题,不管是我自己写的代码,还是在网上找的都输出不对,在多次尝试后,将最终的输出由n-s改为s后通过. #include<stdio.h> #include& ...

最新文章

1. [微信小程序]单选框以及多选框实例代码附讲解
2. html地图周边搜索,html5 百度地图定位关键字搜索附近
3. MySQL之性能优化解说
4. linux PHP ppt 转图片,linux下用php将doc、ppt转图片
5. 开源Math.NET基础数学类库使用(04)C#解析Matrix Marke数据格式
6. 用WebORB实现flex + .net后台的Remoting
7. 在Javascript中实现伪哈希表
8. iphone如何分屏_苹果手机如何操作分屏 苹果手机录屏没有声音这么做轻松解决...
9. codeigniter index.php,CodeIgniter如何隐藏index.php | 学步园
10. buffer pool mysql_理解Mysql中的Buffer pool
11. 【Zigbee】进阶篇(1) Zigbee协议栈创建简单项目，协议栈、事件、消息学习
12. 群联PS2251-07主控(Kingston64G)量产CD-ROM+移动磁盘模式过程记录
13. 人工神经元模型及常见激活函数
14. 中国电信中国电信物联网开放平台-连接管理子系统 http返回为空
15. 小米路由器无线网无法连接到服务器,小米路由器桥接后进不了路由器设置
16. 内核特征码搜索 获取未导出函数
17. TODA WMS（仓库管理系统）简介
18. 手把手教你使用Travis CI自动部署你的Hexo博客到Github上
19. 2022-2028全球纳秒光纤激光器行业调研及趋势分析报告
20. Ubuntu 18.04 安装 NVIDIA 显卡驱动

热门文章

1. Appscan漏洞之Authentication Bypass Using HTTP Verb Tampering
2. 毕业生论文必备！！让英文摘要不是难事
3. 苹果服务器文件夹共享权限设置,苹果设备如何访问 Windows 文件共享？
4. mac显示所有文件后缀名
5. Guass-Legendre（高斯-勒让德）求积方法 | Guass型求积公式 + Legendre多项式
6. android studio umake,Android Studio中NDK开发傻瓜教程（CMake）
7. ubuntu或者Ubuntu Kylin下安装Visual Studio Code
8. 一文学会如何做电商数据分析（附运营分析指标框架）
9. mysql连接失败问题
10. 黑苹果系统--Parallels Desktop虚拟机使用