A002-186-2623-余友龙

A002-186-2623-余友龙

问题域(problem domain)

名词定义

A problem domain is the area of expertise or application that needs to be examined to solve a problem. A problem domain is simply looking at only the topics of an individual’s interest, and excluding everything else. For example, when developing a system to measure good practice in medicine, carpet drawings at hospitals would not be included in the problem domain. In this example, the domain refers to relevant topics solely within the delimited area of interest: medicine. This points to a limitation of an overly specific, or overly bounded, problem domain. An individual may think they are interested in medicine and not interior design, but a better solution exists outside of the problem domain as it was initially conceived. For example, when IDEO researchers noticed that patients in hospitals spent a huge amount of time staring at acoustic ceiling tiles, which “became a symbol of the overall ambiance: a mix of boredom and anxiety from feeling lost, uninformed, and out of control.”
For example, the problem area of our group’s personnel management system is the human resource allocation of the company’s internal personnel, the transfer of staff positions and the promotion and demotion of staff business management. Need to modify employee information in the data, text modification is too complicated, not easy to modify efficiency. Company employees need to ask the personnel department for information, increase the workload of the personnel department.
问题领域是需要检查以解决问题的专门知识或应用领域。 问题领域只是简单地看一个人感兴趣的话题,并排除其他一切。 例如,在开发一个系统来衡量医疗方面的良好做法时,医院的地毯图纸将不包括在问题领域。 在这个例子中,域指的是仅在划定的兴趣范围内的相关主题:医学。 这指出了一个过于特定或过于有限的问题域的限制。 一个人可能认为他们对医学感兴趣,而不是室内设计,但一个更好的解决方案存在于问题领域之外,因为它是最初设想的。 例如,当IDEO的研究人员注意到医院的病人花了大量的时间盯着声学天花板,这“成为了整体氛围的象征:一种无聊和焦虑的混合,因为感觉迷失、不知情和失控。”
又如我们组的人事管理系统的问题域是公司人事部门对公司内部人员进行人力资源分配,调用员工职位以及对员工升职降职等业务管理等操作,需要在资料中对员工信息等进行修改,文本修改过于繁杂,不易修改效率等下。公司员工询问公司信息需要向人事部门询问,加大人事部门的工作量。

参考文献

链接: https://softwareengineering.stackexchange.com/questions/125926/what-is-problem-domain.
http://wiki.c2.com/?ProblemDomain.
https://www.definitions.net/definition/Problem%20domain.

项目联系

公司人事部门对公司内部人员进行人力资源分配,调用员工职位以及对员工升职降职等业务管理等操作,需要在资料中对员工信息等进行修改,文本修改过于繁杂,不易修改效率等下。
公司员工询问公司信息需要向人事部门询问,加大人事部门的工作量。

需求分析(Requirements analysis)

名词定义

Requirement Analysis, also known as Requirement Engineering, is the process of defining user expectations for a new software being built or modified. In software engineering, it is sometimes referred to loosely by names such as requirements gathering or requirements capturing. Requirements analysis encompasses those tasks that go into determining the needs or conditions to meet for a new or altered product or project, taking account of the possibly conflicting requirements of the various stakeholders, analyzing, documenting, validating and managing software or system requirements. Here are the objectives for performing requirement analysis in the early stage of a software project:
From What to How: Software engineering task bridging the gap between system requirements engineering and software design.
3 Orthogonal Views: Provides software designer with a model of:
system information (static view)
function (functional view)
behavior (dynamic view)
Software Architecture: Model can be translated to data, architectural, and component-level designs.
Iterative and Incremental Process: Expect to do a little bit of design during analysis and a little bit of analysis during design.
需求分析,也称为需求工程,是定义用户对正在构建或修改的新软件的期望的过程。 在软件工程中,它有时被松散地称为名称,如需求收集或需求捕获。 需求分析包括那些用于确定新的或更改的产品或项目所需满足的需求或条件的任务,同时考虑到各种利益相关者可能相互冲突的需求,分析、记录、验证和管理软件或系统需求。 以下是在软件项目的早期阶段执行需求分析的目标:
从什么到如何:软件工程任务弥合系统需求工程和软件设计之间的差距。
3正交视图:为软件设计人员提供模型:
系统信息(静态视图)
功能(功能视图)
行为(动态视图)
软件体系结构:模型可以转换为数据、体系结构和组件级设计。
迭代和增量过程:期望在分析过程中做一点设计,在设计过程中做一点分析。

参考文献

链接:
https://www.visual-paradigm.com/guide/requirements-gathering/requirement-analysis-techniques/.
https://reqtest.com/requirements-blog/requirements-analysis/.
http://moodle.autolab.uni-pannon.hu/Mecha_tananyag/szoftverfejlesztesi_folyamatok_angol/ch07.html.

项目联系

软件需求分析就是把软件计划期间建立的软件可行性分析求精和细化,分析各种可能的解法,并且分配给各个软件元素。需求分析是软件定义阶段中的最后一步,是确定系统必须完成哪些工作,也就是对目标系统提出完整、准确、清晰、具体的要求。
软件需求分析的任务是:深入描述软件的功能和性能,确定软件设计的约束和软件同其他系统元素的接口细节,定义软件的其他有效性需求,借助于当前系统的逻辑模型导出目标系统逻辑模型,解决目标系统“做什么”的问题。
![Alt]在这里插入图片描述

类模型(Class model)

Classes are standard UML constructs that specify patterns from which objects will be generated at run time.A class is a specification of an object, an instance of a class.Classes can inherit from other classes (that is, they inherit all the behavior and state of their parent class and add their own new functionality), delegate other classes as properties, delegate responsibilities to other classes, and implement abstract interfaces.The class model is the core of object-oriented development and design. It expresses the persistent state and behavior of the system.Classes encapsulate state (properties) and provide services to manipulate state (behavior).Good object-oriented design limits direct access to class properties and provides services that manipulate properties on behalf of callers.This way of hiding data and exposing services ensures that data updates can only be done in one place according to specific rules – for large systems, the burden of code maintenance to directly access data elements in many places is very high.
The class model shows the static class objects (naming boxes) and their relationships (rows) in an object-oriented software system.The two important relationships are generalization (inheritance) and aggregation (whole-part).Each class object on the diagram typically displays the class name, properties, and actions.Details such as the data type of the property and the parameters of the property can also be shown in the figure as symbols.Many class modeling notations are available, but most developers have standardized UML.
Note that this class has three different areas:

  • Class name (and stereotype, if applied)
  • Page class attribute area (that is, internal data elements)
  • Behavior – private and public
    Properties and methods can be marked as
    Private, said outside the caller is not visible
    protected, they are only visible to the children
    if it is open, everyone can see
    类是标准的UML构造,用于详细说明在运行时将从哪些对象生成的模式。类是一种规范一个对象,一个类的实例。类可以从其他类继承(也就是说,它们继承父类的所有行为和状态,并添加自己的新功能),将其他类作为属性,委托给其他类的职责,并实现抽象接口。类模型是面向对象开发和设计的核心,它表达了系统的持久状态和系统的行为。类封装状态(属性)并提供服务来操作状态(行为)。好的面向对象设计限制了对类属性的直接访问,并提供了代表调用者操纵属性的服务。这种隐藏数据和公开服务的方式确保了数据更新只能在一个地方根据特定的规则完成——对于大型系统来说,直接访问许多地方的数据元素的代码维护负担非常高。
    类模型显示了面向对象软件系统中的静态类对象(命名框)以及它们之间的关系(行)。两个重要的关系是泛化(继承)和聚合(整体-部分)。图上的每个类对象通常显示类名、属性和操作。图中还可以显示属性的数据类型和属性的参数等细节,以作为一些符号。许多类建模符号都是可用的,但是大多数开发人员已经对UML进行了标准化。

请注意这个类有三个不同的区域:

  1. 类名(和原型,如果应用)
  2. 页面类属性区域(即内部数据元素)
  3. 行为-私人和公共

属性和方法可以标记为
私,说外面来电者是看不见的
受保护,他们只对孩子们可见
如果它是开放的,每个人都可以看到

参考文献

链接:
https://www.excelsoftware.com/classmodel.
https://www.uml.org/HTB_Articulate_Class_Models_OMG.pdf.

项目联系

类模型是面向对象开发和设计的核心,它表达了系统的持久状态和系统的行为。类封装状态(属性)并提供服务来操作状态(行为)。好的面向对象设计限制了对类属性的直接访问,并提供了代表调用者操纵属性的服务。这种隐藏数据和公开服务的方式确保了数据更新只能在一个地方根据特定的规则完成——对于大型系统来说,直接访问许多地方的数据元素的代码维护负担非常高。

行为模式(Behavior model)

名词定义

What is behavior modeling?Behavioral models are a way for companies to better understand and predict consumer behavior.Behavioral models use available consumer and business spending data to estimate future behavior in a given situation.Behavioral models are used by financial institutions to estimate the risks associated with providing capital to individuals or businesses, and by marketing companies to target advertising.Behavioral economics also relies on behavioral models to predict the behavior of agents whose behavior is not based solely on facts or reason.
UML behavior diagrams describe time-dependent system elements and convey the dynamic concepts of the system and how they relate to each other.The elements in these diagrams are similar to verbs in natural language, and their relationships often convey the passage of time.For example, the behavior diagram of a vehicle reservation system might contain elements such as booking, renting a car, or providing credit card details.Experienced modelers will display relationships to structural elements on these diagrams.
Behavioral models simply attempt to capture some of the psychology of decision making in order to better simulate how consumers make decisions and the likelihood that a particular consumer will make one choice over another.Behavioral models are used by companies to refine their value proposition in targeted marketing campaigns based on the output of the models.In this sense, behavioral models mainly include analyzing data and classifying people with similar habits and purchasing motives.
Financial institutions, such as banks and credit card companies, use behavioral models to segment and analyze the users of their services.
For example, the credit card company checks the type of business the card is typically used for, the location of the store, the frequency and amount of each purchase to estimate future purchases and whether the cardholder is likely to have repayment problems.
This data is typically aggregated into groups of customers with similar requirements and usage patterns.Specific groups of customers may be offered different promotions to encourage more credit card use, or even to consolidate other debts into existing accounts
什么是行为建模?行为模型是公司用来更好地理解和预测消费者行为的一种方法。行为模型使用可用的消费者和企业支出数据来估计未来在特定情况下的行为。行为模型被金融机构用来估计与向个人或企业提供资金相关的风险,也被营销公司用于目标广告。行为经济学也依赖于行为模型来预测行为主体的行为,这些行为主体的行为不属于完全基于事实或理性的行为。
UML行为图描述了依赖于时间的系统元素,并传达了系统的动态概念以及它们之间如何相互关联。这些图中的元素类似于自然语言中的动词,它们之间的关系通常传达了时间的流逝。例如,一个车辆预订系统的行为图可能包含诸如预订、租车或提供信用卡详细信息等元素。有经验的建模者将在这些图上显示与结构元素的关系。
行为模型只是试图捕捉决策制定的一些心理,以便更好地模拟消费者是如何做出决策的,以及特定消费者做出一种选择而非另一种选择的可能性。行为模型被公司用来根据模型的输出在目标营销活动中完善他们的价值主张。从这个意义上说,行为模型主要包括分析数据,对拥有相似习惯和购买动机的人群进行分类。
金融机构,如银行和信用卡公司,使用行为模型来细分和分析他们服务的用户。例如,信用卡公司会检查信用卡通常使用的业务类型、商店的位置、每次购买的频率和金额,以估计未来的购买行为,以及持卡人是否可能遇到还款问题。这些数据通常被聚合到具有相似需求和使用模式的客户组中。特定群体的客户可能会被提供不同的促销活动,以鼓励更多的信用卡使用,甚至将其他债务合并到现有账户中。

参考文献

链接:
https://www.sparxsystems.com/enterprise_architect_user_guide/14.0/model_domains/behavioraldiagrams.html.
https://www.investopedia.com/terms/b/behavioral-modeling.asp.

项目联系

在每个模型中,都要侧重点表达自己的图表要表达的意思,以下图为例,这是一个层次视角(Layered Viewpoint) 的一部分,在层次视角中侧重点表达某个层次的功能内容以及步骤本项目的登记用户信息功能。
在这里插入图片描述

5.变速控制委员会(Change control board)

名词定义

A change Control board is a committee that evaluates and prioritizes change requests in the context of a project, operation, or service management.During the project life cycle, change is inevitable.To minimize the negative impact of change, the project manager should implement an appropriate change management plan.If you want to learn more about the change management process, you can find more information in the PMP certification course, as this is a very important aspect of project integration management.
All of these change requests are evaluated by the CCB.Any project is at risk of failure if the change request is not evaluated against the change management framework.
What are the responsibilities of the CHANGE Control board?A Change Control Board is referred to as a Change Control Board.Many projects have a change control board.
Because the project will receive change requests that have to be evaluated by the CHANGE Control Board.
Who is on the CHANGE Control Board?The people included in the Change Control repository should be documented in the Change management plan.The board of directors may include project managers, experts, clients, and sponsors.They are the ones who assess change and its impact.Then approve or reject the changes.
变更控制委员会是一个委员会,它在项目、操作或服务管理的环境中评估并确定变更请求的优先级。在项目生命周期中,更改是不可避免的。为了尽量减少变更的负面影响,项目经理应实施适当的变更管理计划。如果你想了解更多关于变更管理过程的信息,你可以在PMP认证课程中找到更多的信息,因为这是项目集成管理的一个非常重要的方面。所有这些变更请求都由变更控制委员会进行评估。如果没有根据变更管理框架评估变更请求,任何项目都有失败的风险。
变更控制委员会的职责是什么?变更控制委员会简称变更控制委员会。许多项目都有一个变更控制板。因为项目会收到变更请求这些必须由变更控制委员会评估。
变更控制委员会中包括谁?包含在变更控制库中的人员,应在变更管理计划中记录。董事会可包括项目经理、专家、客户和赞助商。他们是评估变化及其影响的人。然后批准或拒绝更改。

参考文献

链接:
https://simplicable.com/new/change-control-board.
https://blog.masterofproject.com/change-control-board/.

项目联系

项目变更控制委员会或更完整的配置控制委员会(Configuration Control Board, CCB),或相关职能的类似组织,是项目的所有者权益代表,负责裁定接受哪些变更。CCB由项目所涉及的多方人员共同组成,通常包括用户和实施方的决策人员。
项目变更控制委员会(Change Control Board,简称CCB)。变更控制委员会要定期召开会议,对近期所产生的变更请求进行分析、整理,并做出决定。而且要遵循一定的变更机制。
项目变更控制委员会(Change Control Board,CCB)组成:项目双方项目管理人员(部门领导、高层经理、项目经理)、技术人员(开发人员、测试负责人、质量保证负责人QA)、商务人员。

合作图(collaboration diagram)

名词定义

A collaboration diagram (called a communication diagram in UML 2.x) is used to show how objects interact to perform the behavior of a particular use case, or part of a use case.Along with sequence diagrams, collaborations are used by designers to define and clarify the role of objects that execute a use-case specific flow of events.They are the primary source of information for determining class responsibilities and interfaces.
What is collaboration?A collaboration is a collection of named objects and actors with links between them.They collaborated on a task.Collaboration defines a set of participants and meaningful relationship to a given set purpose, in an object-oriented system, work with the object of collaboration between ideal provided emergency function, each object (duty) to support the emergency function, objects can work together to produce (available) by advanced features, object collaboration through mutual communication (the message), in order to work together.
Collaboration diagrams are similar to flowcharts in that they describe the roles, functions, and behaviors of individual objects, as well as the overall operation of the system, in real time.
The four main components of a collaboration map are:

  1. Object – The object appears as a rectangle with a named tag inside.
    Naming tags follow the convention for object names: class names.
    This should also be noted if an object has specific properties or states that affect the collaboration
  2. Actor - An actor is an instance of the interaction in the invocation diagram.
    Each actor has a name and a role, and one actor initiates the entire use case.
  3. Links – Links connect objects with participants and are described with solid lines between the two elements.
    Each link is an instance where a message can be sent.
  4. Message-messages between objects appear as labeled arrows placed near links.
    These messages are communication between objects, passing information about the activity, and can include a sequence number.
    协作图(在UML 2.x中称为通信图)用于显示对象如何交互以执行特定用例的行为,或者用例的一部分。与序列图一起,协作被设计人员用来定义和阐明执行用例特定事件流的对象的角色。它们是用于确定类职责和接口的主要信息源。
    什么是协作?协作是命名对象和参与者的集合,它们之间有链接。他们合作完成某项任务。协作定义了一组参与者和对一组给定目的有意义的关系,在面向对象的系统中,一起工作的对象之间的协作提供了紧急的理想功能,每个对象(职责)部分支持紧急功能,对象能够通过协同工作产生(可用的)高级功能,对象通过相互通信(传递消息)来协作,以便共同工作。
    协作图类似于流程图,它描述了实时地描述单个对象的角色、功能和行为,以及系统的整体操作。协作图的四个主要组成部分是:
    1.对象——对象显示为内部带有命名标签的矩形。命名标签遵循对象名的约定:类名。如果一个对象具有特定影响协作的属性或状态,也应该注意这一点
    2.参与者-参与者是调用图中的交互的实例。每个参与者都有一个名字和一个角色,一个参与者发起整个用例。
    3.链接——链接用参与者连接对象,并在两个元素之间使用实线进行描述。每个链接都是可以发送消息的实例。
    4.消息-对象之间的消息显示为放置在链接附近的带标签的箭头。这些消息是对象之间的通信,传递关于活动的信息,可以包括序列号。

参考文献

链接:
https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-uml-collaboration-diagram/.
https://searchsoftwarequality.techtarget.com/definition/collaboration-diagram.
https://www.tutorialandexample.com/collaboration-diagram/.

项目联系

在这里插入图片描述
在这里插入图片描述

交互图(interaction diagram)

名词定义

As the name implies, an interaction diagram depicts the interaction between different entities in the model.It combines an activity diagram and a sequence diagram.Communication is nothing more than a unit of behavior for a classifier that provides context for an interaction.A set of messages exchanged between entities to accomplish a specific task in the system is called an interaction.It can contain any characteristics of the classifier it accesses.
In the interaction diagram, the key components in UML are messages and lifelines, and the interaction overview diagram uses messaging to initiate interactions between objects.When drawing an interaction diagram, the whole point is to represent the relationships between the different objects available within the boundaries of the system and the messages they exchange to communicate with each other.The information exchanged between objects is either passing information or requesting information.
According to the information, the interaction diagram is divided into sequence diagram, collaboration diagram and sequence diagram.By describing the communication between two lifelines, a sequence diagram envisions the sequence of message flows within a system, much like a chronological sequence of events.
A collaboration diagram, also known as an exchange diagram, shows how lifelines are connected in a system, while a time diagram focuses on the moment a message is passed from one element to another.
Interaction diagrams help visualize the interactive (dynamic) behavior of any system.
It describes how objects residing in the system communicate and connect to each other.
It also provides an environment for communication between lifelines within a system.
Here is the purpose of the interaction diagram:
1.Visualize the dynamic behavior of the system.
2.Imagine the interactions and message flows in the system.
3.Describes the structural aspects of entities within a system.
4.Represents the order of the ordered interactions in the system.
5.Visualizes real-time data and represents the architecture of object-oriented systems.
顾名思义,交互图描绘了模型中不同实体之间的交互。它合并了活动图和序列图。通信只不过是为交互提供上下文的分类器的行为单元。在实体之间交换以实现系统中特定任务的一组消息被称为交互。它可以包含它所访问的分类器的任何特征。在交互图中,UML中的关键组件是消息和生命线,交互概述图利用消息传递启动对象之间的交互。在绘制交互图时,整个重点是表示系统边界内可用的不同对象之间的关系,以及它们之间为相互通信而交换的消息。对象之间交换的信息要么是传递信息,要么是请求信息。并根据这些信息,将交互图分为顺序图、协作图和时序图。序列图通过描述两条生命线之间的通信,设想了系统内消息流的顺序,就像时间顺序的事件序列。协作图,也被称为交流图,表示生命线在系统中是如何连接的,而时间图关注的是消息从一个元素传递到另一个元素的瞬间。
交互图有助于设想任何系统的交互(动态)行为。它描述驻留在系统中的对象如何相互通信和连接。它还为我们提供了系统内生命线之间通信的环境。
下面是交互图的目的:
1.使系统的动态行为形象化。
2.设想系统中的交互和消息流。
3.描述系统内实体的结构方面。
4.表示系统中已排序的交互作用的顺序。
5.使实时数据可视化,并表示面向对象系统的体系结构。

参考文献

链接:
https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-interaction-overview-diagram/.
https://www.javatpoint.com/uml-interaction-diagram.
https://www.tutorialspoint.com/uml/uml_interaction_diagram.htm.

名词定义

本项目的功能系统的交互(动态)行为,控制流从一个元素到系统内其他元素的顺序,描述了驻留在系统中的功能如何调用其他功能还有对数据库的管理。如图以下只是部分功能的交互图。
在这里插入图片描述

内外关系图(Context diagram)

名词定义

What is a system context diagram?Imagine that you need to have a general understanding of an automated ordering system.Wouldn’t it be helpful if you could develop a high-level view of the system without getting bogged down in all the details?This is what the system context diagram can do for you.This is a picture worth a thousand words…Even 10,000 words, if this is a very large system.You can think of a system context diagram as a high-level map of the system and its surroundings.Drawing a context diagram helps you understand how the system interacts with other systems, business units, and key people.In addition, you can use it to help define the scope of system operations.The system context diagram is drawn using only three diagram elements: the context bubble, the external entity, and the data stream.
The environment diagram displays the system under consideration as a single high-level process, and then shows the relationship of the system to other external entities (systems, organizational groups, external data stores, and so on).Another name for a context diagram is a context-level data flow diagram or a level-0 data flow diagram.Since context diagrams are specialized versions of data flow diagrams, it helps to know a little about data flow diagrams (DFDS), which are graphical visualizations of data moving through an information system.DFDs is one of the three important components of structural systems Analysis and Design method (SSADM).The DFD is process-centric and describes four main components:
process (round)
external entities (rectangular)
data storage (two horizontal, parallel lines, or sometimes and ellipse)
data flow (with arrow flow curve or straight line)
Each DFD may show multiple processes, with data flowing in and out of each process.
If you need to show more detail in a particular process, the process is broken down into many smaller processes in a lower level DFD.In this way.A content graph or context-level DFD is marked as a “level 0 DFD”, and the next decomposition level is marked as a “level 1 DFD”.
The next is labeled “level-2 DFD,” and so on.Context diagrams and data flow diagrams are created for system analysis and design.But like many analytical tools, they are also used for other purposes.For example, they can also be used to capture and communicate interactions and data flows between business processes.They don’t have to be limited to system analysis.
什么是系统上下文图?想象一下,您需要对自动订购系统有一个大致的了解。如果您可以开发该系统的高级视图,而不陷入所有处理细节的泥沼,会不会有帮助呢?这就是系统上下文图能为您做的事情。这是一张胜过千言万语的图片……甚至一万字,如果这是一个非常大的系统。您可以将系统上下文图看作是系统及其周围环境的高级映射。绘制上下文图可以帮助您理解系统如何与其他系统、业务单元和关键人员进行交互。此外,您可以使用它来帮助定义系统操作的范围。系统上下文图只使用三种图表元素绘制,它们是上下文气泡、外部实体和数据流。
环境图将考虑中的系统显示为单个高级流程,然后显示系统与其他外部实体(系统、组织组、外部数据存储等)的关系。上下文图的另一个名称是上下文级数据流图或0级数据流图。由于上下文图是数据流图的专门版本,所以对数据流图有一点了解会有所帮助数据流图(DFD)是数据通过信息系统移动的图形化可视化。DFDs是结构系统分析与设计方法(SSADM)的三个重要组成部分之一。DFD以过程为中心,描述了4个主要组件:
流程(圆)
外部实体(矩形)
数据存储(两条水平、平行线或有时和椭圆)
数据流(带箭头指示流向的曲线或直线)
每个DFD可能会显示多个流程,每个流程都有数据流入和流出。如果需要在一个特定的过程中显示更多的细节,该过程在一个较低层次的DFD中分解成许多较小的过程。以这种方式。内容图或上下文级别的DFD被标记为“0级DFD”,而下一个分解级别被标记为“1级DFD”。下一个则标记为“Level-2 DFD”,依此类推。为系统分析和设计创建了上下文图和数据流图。但像许多分析工具一样,它们也被用于其他目的。例如,还可以利用它们来捕获和通信业务流程之间的交互和数据流。它们不必局限于系统分析。

参考文献

链接:
https://www.modernanalyst.com/Careers/InterviewQuestions/tabid/128/ID/1433/What-is-a-Context-Diagram-and-what-are-the-benefits-of-creating-one.aspx.
https://stackoverflow.com/questions/23761522/uml-replacement-for-context-diagram.
https://study.com/academy/lesson/system-context-diagram-description-examples.html#partialRegFormModal.

项目联系

本项目的上下文图描述了分配和存储员工信息的计算机化系统中的必要组件。它帮助公司老板管理他们的员工信息和公司的业务流程,允许他们更新他们的信息,并使他们在他们的系统中信息上可见。
上下文图用于显示公司人事管理系统软件和与其交互的硬件。箭头指示在软件和每个硬件组件之间流动的数据的方向和类型。
用于显示由老板、员工、管理层和请假系统组成的外部组件之间的关系。它非常适合于确保所有参与方都在同一页面上,并且在不同的高级层次上定义业务项目的范围。

判定表(Decision table)

名词定义

What is a decision table?Decision tables provide a convenient and concise way to represent complex business logic.In the decision table, the business logic is well divided into conditions, actions (decisions), and rules that represent the various components that make up the business logic.
What can a decision table do?Decision table is a decision making method that considers various conditions and their interrelations, especially complex interrelations.People use decision tables to represent and discover business logic, which ultimately leads to better business.
什么是决策表?决策表提供了一种方便而简洁的方法来表示复杂的业务逻辑。在决策表中,业务逻辑被很好地划分为表示构成业务逻辑的各种组件的条件、操作(决策)和规则。
决策表能做什么?决策表是一种考虑各种条件及其相互关系的决策方法,尤其是复杂的相互关系。人们使用决策表来表示和发现业务逻辑,这最终导致更好的业务。

参考文献

链接:
https://www.sparxsystems.com/enterprise_architect_user_guide/14.0/model_domains/dmn_expression_decisiontable.html.
https://www.visual-paradigm.com/product/articles/decision-table-explained/.
https://www.ibm.com/developerworks/rational/library/jun06/vauthier/index.html.

项目联系

在这里插入图片描述

需求诱导(Requirements elicitation)

名词定义

A Requirement is a feature that the system must have or a constraint that it must satisfy to be acceptable to the client. The Requirements Process is aimed at defining the requirements of the system under construction. The Requirements Process can be viewed as two main activities, Requirements Elicitation, which results in the specification of the system that the customer understands, and Requirements Analysis, which results into an analysis model that the
developers can unambiguously interpret. Requirements elicitation is the most challenging of the two given that it requires the collaboration of several groups of participants who have different backgrounds. On the one hand, the client and the users have a solid background in their domain and have a general idea of what the system should do. However, they may
have little experience in software development or interface design. On the other hand, the
developers have experience in building systems but may have little knowledge of the everyday environment of the users. Moreover, each group may be using incompatible terminologies.
Scenarios and use cases provide tools for bridging this gap. A scenario describes an example of use of the system in terms of a series of interactions between the user and the system. A use case is an abstraction that describes a class of scenarios. Both scenarios and use cases are written in natural language, a form that is understandable to the user.
需求是系统必须具有的特性或它必须满足的约束客户可以接受。需求过程的目的是定义系统建设。需求过程可以被看作两个主要的活动,需求引出,其结果是客户对系统的规格说明了解,并进行需求分析,从而得出一个分析模型开发人员可以明确地解释。需求引出是最具挑战性的考虑到这需要几组参与者的合作不同的背景。一方面,客户端和用户都有坚实的背景他们的领域,并对系统应该做什么有一个总体的想法。然而,他们可能缺乏软件开发或界面设计经验。另一方面,开发人员有构建系统的经验,但可能很少了解用户的日常生活环境。而且,每个群体都可能使用不兼容术语。
场景和用例提供了弥合这一差距的工具。场景描述一个示例系统的使用是指用户和系统之间的一系列交互作用。
一个用例是描述一类场景的抽象。场景和用例都是用自然语言编写的,用户可以理解的形式。

参考文献

链接:
https://dademuch.com/2017/09/28/requirements-elicitation/.
https://ase.in.tum.de/paid.globalse.org/paid1/courseDocs/Readings/ReqElicitation030398.pdf.
https://www.cs.fsu.edu/~baker/swe1/restricted/notes/requirements.html.

项目联系

对业务需求的彻底发现在分析师的指尖几乎是不容易找到的——仅仅是需求可以被快速查找,因为人们会为学期论文收集信息或为测试进行研究。 许多业务或技术要求在任何地方都没有记录在案-它存在于利益相关者的头脑中,存在于尚未从最终用户获得的反馈中,也存在于尚未创建的流程图和调查的研究中。 因此,必须提出要求,或提出要求,这样做的方法必须合乎逻辑和细致。 激发的重要性怎么强调都不为过,因为它是任何需求项目的关键。

状态化分析(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.
Objectives of structured analysis,structured analysis became popular in the 1980s and is still in use today. [ citation needed ] Structured analysis consists of interpreting the system concept (or real world situations) into data and control terminology represented by data flow diagrams. The flow of data and control from bubble to the data store to bubble can be difficult to track and the number of bubbles can increase.
One approach is to first define events from the outside world that require the system to react, then assign a bubble to that event. Bubbles that need to interact are then connected until the system is defined. Bubbles are usually grouped into higher level bubbles to decrease complexity. Data dictionaries are needed to describe the data and command flows, and a process specification is needed to capture the transaction/transformation information.
SA and SD are displayed with structure charts, data flow diagrams and data model diagrams, of which there were many variations, including those developed by Tom DeMarco, Ken Orr, Larry Constantine, Vaughn Frick, Ed Yourdon, Steven Ward, Peter Chen, and others.
These techniques were combined in various published system development methodologies, including structured systems analysis and design method, profitable information by design (PRIDE), Nastec structured analysis & design, SDM/70 and the Spectrum structured system development methodology.
什么是结构分析?结构化分析是一种开发方法,它允许分析人员以一种有逻辑的方式来理解系统及其活动。它是一种系统的方法,它使用图形工具来分析和细化现有系统的目标,并开发一个用户容易理解的新系统规范。
它有以下属性:
它是指定应用程序的表示的图形。
它划分了各个过程,因此它给出了一个清晰的系统流程图。
它是逻辑的,而不是物理的,也就是说,系统的元素不依赖于供应商或硬件。
这是一种从高层概述到低层细节工作的方法。
结构分析的目标,结构化分析在20世纪80年代开始流行,至今仍在使用。结构化分析包括将系统概念(或真实世界情况)解释为数据流图表示的数据和控制术语。从气泡到数据存储到气泡的数据流和控制可能很难跟踪,而且气泡的数量可能会增加。
一种方法是首先从外部世界定义需要系统作出反应的事件,然后为该事件分配一个气泡。需要相互作用的气泡被连接起来,直到系统被定义。气泡通常被分组成更高级别的气泡以减少复杂性。需要数据字典来描述数据和命令流,需要流程规范来捕获事务/转换信息。
SA和SD用结构图、数据流图和数据模型图来显示,其中有许多变体,包括Tom DeMarco、Ken Orr、Larry Constantine、Vaughn Frick、Ed Yourdon、Steven Ward、Peter Chen等人开发的那些变体。
这些技术被结合在各种已发表的系统开发方法中,包括结构化系统分析和设计方法,通过设计盈利信息(PRIDE), Nastec结构化分析和设计,SDM/70和Spectrum结构化系统开发方法。

参考文献

链接:
https://wikimili.com/en/Structured_analysis.
https://www.tutorialspoint.com/system_analysis_and_design/system_analysis_and_design_structured.htm.
https://encyclopedia2.thefreedictionary.com/structured+analysis.

项目联系

在结构化分析过程中,各种工具和技术用于系统开发。它们是:
数据流图、数据字典、决策树、决策表、结构化英语、伪码
在这里插入图片描述
本项目在结构化分析过程中使用了数据流图和数据字典等来对系统进行结构化分析,由于系统尚未实现,对其进行需求分析时,其伪码也为进行编写,未能展示出来。

系统边界(System boundary)

名词定义

System boundary elements are non-UML elements used to define conceptual boundaries.You can use system boundaries to help group logically related elements (from a visual perspective, rather than as part of a UML model).
In UML superstructure specification V2.1.1, system boundaries are described in the use case section, because system boundaries are often used to indicate the application of a use case to another entity.
In this case, the system boundary:
Encloses the Use Case
Is associated with a classifier such as a Class, Component or Subsystem (Actor) through the 'Select ’ dialog
By associating system boundaries – not use cases – with classifiers, classifiers are linked to use cases as users rather than owners.You can also define use cases as classifiers for system boundary elements to associate elements contained in system boundaries (such as parts of activity diagrams) with representations in logical use cases.The element attributes of the system boundary element include the name, the boundary style, and the number of horizontal or vertical swimlanes.
You can also change the overall shape of the system boundaries, which includes the option to add a boundary to the element instead of using swimlanes, and you can make the element completely opaque, completely transparent, or set varying degrees of opacity between the two.System boundary elements can be marked “optional” using the element’s context menu.When an element is not optional, you can click another element in the system boundary space without having to activate or select the system boundary itself.
系统边界元素是用于定义概念边界的非uml元素。您可以使用系统边界来帮助对逻辑上相关的元素进行分组(从可视化的角度来看,而不是作为UML模型的一部分)。
在UML上层结构规范v2.1.1中,系统边界是在用例部分中描述的,因为系统边界经常用于指示用例对另一个实体的应用。
在这种情况下,系统边界:
封装用例
是否通过’Select '对话框与分类器(如类、组件或子系统(参与者))相关联
通过将系统边界—而不是用例—与分类器相关联,分类器作为用户而不是所有者链接到用例。您还可以将用例定义为系统边界元素的分类器,以将系统边界(例如活动图的部分)中包含的元素与逻辑用例中的表示联系起来。系统边界元素的元素属性包括名称、边界样式和水平或垂直泳道的数量。您还可以更改系统边界的整体形状,这包括向元素添加分界线而不是使用泳道的选项,并且您可以使元素完全不透明、完全透明或在两者之间设置不同程度的不透明度。系统边界元素可以被标记为“可选择”,使用元素的上下文菜单。当元素不可选时,您可以单击系统边界空间中的其他元素,而无需激活或选择系统边界本身。

参考文献

链接:
https://documentation.help/StarUML/system_boundary.htm.
https://sparxsystems.com/enterprise_architect_user_guide/15.1/model_domains/systemboundary.html.
https://www.visual-paradigm.com/VPGallery/usecase/SystemBoundary.html.

项目联系

用例是一种捕获系统功能需求的技术。用例描述了一个独立于实现细节的期望行为。用例的目标是捕获用户设想的所有系统级功能。从用户的角度来看,用例是关于系统应该做什么的。用例捕获系统利益相关者之间关于其行为的合同。用例描述了系统在各种条件下的行为,因为系统响应来自其中一个利益相关者(称为主要参与者)的请求。
在这里插入图片描述

抽象化(abstraction)

名词定义

Abstraction is a dependency relationship that relates two named elements or sets of named elements representing the same concept but at different levels of abstraction or from different viewpoints.
Because abstraction is dependency, it is usually defined as a relationship between client(s) and supplier(s) where client (subset of source) depends on supplier (subset of target). It corresponds to common OOAD convention to consider more abstract element in the abstraction relationship as a supplier. Nonetheless, UML modeler may decide that for some specific domain or task it is more appropriate to have a more abstract supplier element dependent on the more specific client element.
Abstraction allows mapping between the supplier and the client to be formal or informal, and unidirectional or bidirectional, depending on the specific subclass or stereotype of abstraction. For example, Derivation could be formal and unidirectional, while Trace could be informal and bidirectional.
If an abstraction has more than one client, the supplier maps into the set of clients as a group. For example, an analysis level class could serve as an abstraction for one or several design level classes. Use case could be abstraction for several collaborations.
抽象是两个命名元素或一组命名元素之间的依赖关系,它们代表相同的概念,但处于不同的抽象级别或从不同的视角。
因为抽象是一种依赖关系,它通常被定义为客户端和供应商之间的关系,其中客户端(源的子集)依赖于供应商(目标的子集)。它符合常见的OOAD约定,在抽象关系中作为供应商考虑更抽象的元素。尽管如此,UML建模师可能会决定,对于某些特定的领域或任务,使用依赖于更具体的客户端元素的更抽象的供应商元素更为合适。
抽象允许供应商和客户之间的映射是正式的还是非正式的,单向的还是双向的,这取决于抽象的特定子类或原型。例如,派生可以是正式的、单向的,而跟踪可以是非正式的、双向的。
如果一个抽象有不止一个客户端,那么供应商将作为一个组映射到客户端集合中。例如,一个分析级别的类可以作为一个或多个设计级别类的抽象。用例可以是多个协作的抽象。

参考文献

链接:
https://www.uml-diagrams.org/abstraction.html.
https://www.howtobuildsoftware.com/index.php/how-do/cws1/uml-software-engineering-modeling-software-design-abstraction-what-is-the-differences-between-abstraction-and-decomposition.
https://www.ibm.com/support/knowledgecenter/SS8PJ7_9.7.0/com.ibm.xtools.modeler.doc/topics/cabstract.html.

项目联系

抽象是两个命名元素或一组命名元素之间的依赖关系,它们代表相同的概念,但处于不同的抽象级别或从不同的视角。
抽象允许供应商和客户之间的映射是正式的还是非正式的,单向的还是双向的,这取决于抽象的特定子类或原型。例如,派生可以是正式的、单向的,而跟踪可以是非正式的、双向的。

并发子状态(concurrent substate)

名词定义

UML supports concurrency, and makes it possible to represent the concept in different kinds of diagrams. This article covers the three most commonly used – the activity diagram, sequence diagram, and state machine diagram. Note that the OCUP 2 Foundation level examination covers concurrency only in the activity diagram; concurrency in sequence and state machine diagrams is covered at the Intermediate and Advanced levels.
In activity diagrams, concurrent execution can be shown implicitly or explicitly. If there are two or
more outgoing edges from an action it is considered an implicit split. Two or more incoming edges signify an implicit join.
The action at an implicit join will not execute until at least one token is offered on every incoming
control flow. When the action begins execution, it will consume all tokens offered on all incoming
control flows.
Concurrency can be shown in a sequence diagram using a combined fragment with the par operator
or using a coregion area. A coregion can be used if the exact order of event occurrences on one lifeline is irrelevant or unknown. Coregion is shorthand for parallel combined fragment within a single lifeline.
Concurrency on a state machine diagram can be expressed by an orthogonal state (a composite state with multiple regions). If an entering transition terminates on the edge of the orthogonal state, then all of its regions are entered.
UML支持并发性,并使以不同类型表示概念成为可能图。本文介绍了三个最常用的方法——活动图、序列关系图和状态机关系图。请注意,ocup2基础水平考试涵盖的范围只在活动图中实现并发;序列和状态机关系图中的并发性是涵盖中级和高级水平。
在活动图中,可以隐式或显式地显示并发执行。如果有两个或一个动作的更外向的边缘被认为是隐式分裂。两个或更多进来的边表示隐式连接。
隐式连接上的操作直到对每个传入的操作提供至少一个令牌时才会执行控制流。当操作开始执行时,它将使用所有传入的令牌控制流。
并发性可以在序列图中显示,使用带有par操作符的组合片段或者使用一个上区域。如果事件发生的确切顺序在一个区域上,可以使用一个共区域生命线是无关的或未知的。
“共区”是指在单个片段内并行合并的片段生命线。
状态机图上的并发性可以用正交状态(复合状态)表示多个区域。如果进入跃迁在正交态的边缘终止,则它的所有区域都进入了。

参考文献

链接:
http://etutorials.org/Programming/UML/Chapter+8.+State+Diagrams/Concurrent+State+Diagrams/.
https://stackoverflow.com/questions/7819028/declarative-composite-state-with-concurrent-substates-in-uml.
https://www.omg.org/ocup-2/documents/concurrency_in_uml_version_2.6.pdf.

项目联系

并发性可以在序列图中显示,使用带有par操作符的组合片段或者使用一个上区域。如果事件发生的确切顺序在一个区域上,可以使用一个共区域生命线是无关的或未知的。
“共区”是指在单个片段内并行合并的片段生命线。
状态机图上的并发性可以用正交状态(复合状态)表示多个区域。如果进入跃迁在正交态的边缘终止,则它的所有区域都进入了。

内部过渡(internal transition)

名词定义

If you need to define an internal Transition in a State, you can do so by creating an external self-Transition connector (where the Source and Target are the same State) and then changing the connector kind property. The self-Transition connector is then removed from the diagram and the internal Transition displays in a compartment inside the State element.
Define an Internal Transition:
In the Project Browser, double-click on the StateMachine diagram containing the State element to open it.
On the State element, create a Transition connector issuing from and terminating in the element (a ‘self Transition’).In the Diagram Toolbox, select the Transition connector, then click and release on the State element.
Right-click on the connector and select the ‘Properties’ option to display the ‘Properties’ dialog.
Select the ‘Constraints’ tab and define any guard, effect and trigger for the Transition.
Select the ‘General’ tab, then select the child tab ‘Advanced’. Click on the drop-down arrow in the value field for the kind property and select internal.
Click on the OK button. The Transitions display in the same compartment as internal activities (exit/, do/, entry/).
如果需要在状态中定义内部转换,可以通过创建外部自转换连接器(其中源和目标是相同的状态),然后更改连接器类型属性来实现。然后,自转换连接器将从图中删除,内部转换将显示在State元素内部的分隔单元中。
定义一个内部转换:
在项目浏览器中,双击StateMachine图包含状态元素以打开它。
国家元素,创建一个过渡连接器发行和终止的元素(“自我转型”)。在关系图工具箱中,选择转换连接器,然后单击State元素上的release。
连接器上单击鼠标右键,然后选择“属性”选项来显示“属性”对话框。
选择“限制”选项卡并定义任何卫兵,效应,引发的过渡。
选择“通用”选项卡,然后选择子选项卡“高级”。单击kind属性值字段中的下拉箭头,并选择internal。
点击OK按钮。转换显示在与内部活动(exit/、do/、entry/)相同的区域中。

参考文献

链接:
https://www.sparxsystems.com/enterprise_architect_user_guide/14.0/model_domains/internal_transition.html.
https://sparxsystems.com/enterprise_architect_user_guide/15.0/model_domains/transition.html.
http://www.state-machine.com/qm/sm_tran.html.

项目联系

如果需要在状态中定义内部转换,可以通过创建外部自转换连接器(其中源和目标是相同的状态),然后更改连接器类型属性来实现。然后,自转换连接器将从图中删除,内部转换将显示在State元素内部的分隔单元中。

持久对象(persistent object)

名词定义

Assume that in the NextGen application, ProductSpecification data resides in a relational database. It must be brought into local memory during application use. Persistent objects are those that require persistent storage, such as ProductSpecification instances.
Object databases— If an object database is used to store and retrieve objects, no additional custom or third-party persistence services are required. This is one of several attractions for its use.
Relational databases— Because of the prevalence of RDBs, their use is often required, rather than the more convenient object databases. If this is the case, a number of problems arise due to the mismatch between …
假设在下一代应用程序中,ProductSpecification数据驻留在关系数据库中。在应用程序使用期间,必须将它放入本地内存。持久化对象是那些需要持久化存储的对象,例如ProductSpecification实例。
对象数据库——如果使用对象数据库存储和检索对象,则不需要额外的自定义或第三方持久性服务。这是使用它的几个吸引人的地方之一。
关系数据库——由于RDBs的流行,通常需要使用它们,而不是更方便的对象数据库。如果是这样的话,由于……之间的不匹配,就会产生许多问题。

参考文献

链接:
https://www.oreilly.com/library/view/applying-uml-and/0130925691/0130925691_ch34lev1sec2.html.
https://www.oreilly.com/library/view/java-data-objects/0596002769/ch01s01.html.
https://www.wisdomjobs.com/e-university/uml-tutorial-175/the-problem-persistent-objects-13456.html.

项目联系

对于持久对象的了解还不够深刻,本项目的持久对象很难以分析,持久对象(persistent object)是2018年公布的计算机科学技术名词。

持久对象(persistent object)

名词定义

State History is a convenient concept associated with Regions of Composite States, whereby a Region keeps track of the configuration a State was in when it was last exited. This allows easy return to that State configuration, if necessary, the next time the Region becomes active (for example, after returning from handling an interrupt), or if there is a local Transition that returns to its history.
Enterprise Architect supports two types of History Pseudostate:
Deep History - representing the full State configuration of the most recent visit to the containing Region; the effect is the same as if the Transition terminating on the deepHistory Pseudostate had, instead, terminated on the innermost State of the preserved State configuration, including execution of all entry Behaviors encountered along the way
Shallow History - representing a return to only the top-most substate of the most recent State configuration, which is entered using the default entry rule
状态历史记录是一个与复合状态区域相关联的方便概念,通过该区域可以跟踪某个状态在最后一次退出时的配置。如果有必要,下次区域变得活跃时(例如,处理中断后返回),或者有一个本地转换返回到它的历史记录,就可以轻松地返回到那个状态配置。
企业架构师支持两种类型的历史伪状态:
深历史——代表整个国家最近访问的配置包含地区;其效果与deepHistory伪状态上终止的转换在保留状态配置的最内层状态上终止一样,包括一路上遇到的所有进入行为的执行
浅代表回到历史——只有最顶部的亚态的最近的状态配置,这是进入使用默认条目规则

参考文献

链接:
http://tool.uml.com.cn/ToolsEA/UserGuide/model_simulation/example__history_pseudostate_example.html.
http://www.herongyang.com/UML/State-Machine-Diagram-Pseudostate-Notations.html.
https://www.sparxsystems.com/enterprise_architect_user_guide/14.0/model_domains/pseudo-states.html.

项目联系

本项目在员工入职期间的状态进行描绘,在本系统中,对人事资源的管理进行输入输出,在一名员工入职期间,管理员录入该员工的信息(即状态试用工、基本信息等),在该名员工的试用期观察,对这名员工进行审核考察,查看他是否符合我们的公司的人才需要,试用期结束后,若考核成功,由该员工自己决定去留,留则需要上级批准是否能够成为公司的正式员工。失败则公司将淘汰该员工。这就是本项目员工入职的状态图。
在这里插入图片描述

单继承(single inheritance)

名词定义

Single inheritance is 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.
One way of defining characters in a Fantasy boardgame is to start with a base set of parameters, and then modify them depending on the character’s class (Warrior, Mage, etc.)
单继承是最简单的继承模型。当您有一个具有基本特征的类,并且您需要创建更多具有所有基本特征和一些特定特征的类时,将使用此方法。
在幻想桌面游戏中定义角色的一种方法便是从一组基本参数开始,然后根据角色的职业(游戏邦注:如战士,法师等)去修改它们。

参考文献

链接:
https://core.ac.uk/display/20754526.
https://techdifferences.com/difference-between-single-and-multiple-inheritance.html.
https://www.sciencedirect.com/topics/computer-science/single-inheritance.

项目联系

与上面的多继承进行对比,正如我查阅的资料所说,如果以正确的方式处理单一继承比多重继承更安全。如果派生类或父类构造函数中重写了某个特定方法的父类实现,则它还允许派生类调用该方法的父类实现。在本项目的实现过程中,若可以正确的方式处理单一继承,会不用多重继承,使系统更加安全。

二元关联(binary association)

名词定义

In UML diagrams, an association class is a class that is part of an association relationship between two other classes.
You can attach an association class to an association relationship to provide additional information about the relationship. An association class is identical to other classes and can contain operations, attributes, as well as other associations.
For example, a class called Student represents a student and has an association with a class called Course, which represents an educational course. The Student class can enroll in a course. An association class called Enrollment further defines the relationship between the Student and Course classes by providing section, grade, and semester information related to the association relationship.
在UML图中,关联类是作为其他两个类之间关联关系的一部分的类。
您可以将关联类附加到关联关系,以提供关于该关系的附加信息。关联类与其他类相同,可以包含操作、属性以及其他关联。
例如,一个名为Student的类代表一个学生,并与一个名为Course的类有关联,后者代表一个教育课程。学生班可以注册一门课程。一个名为Enrollment的关联类通过提供与关联关系相关的部分、年级和学期信息,进一步定义了学生和课程类之间的关系。

参考文献

链接:
https://www.uml-diagrams.org/association-reference.html.
https://www.ibm.com/support/knowledgecenter/SSCLKU_7.5.5/com.ibm.xtools.modeler.doc/topics/cassnclss.html.
https://www.dummies.com/business/customers/associations-between-binary-variables/.

项目联系

在UML图中,关联类是作为其他两个类之间关联关系的一部分的类。
您可以将关联类附加到关联关系,以提供关于该关系的附加信息。关联类与其他类相同,可以包含操作、属性以及其他关联。

内容层次结构(containment hierarchy)

名词定义

A containment hierarchy is a hierarchical collection of strictly nested sets. Each entry in the hierarchy designates a set such that the previous entry is a strict superset, and the next entry is a strict subset. For example, all rectangles are quadrilaterals, but not all quadrilaterals are rectangles, and all squares are rectangles, but not all rectangles are squares. A hierarchy of this kind is to be contrasted with a more general notion of a partially ordered set.
包含层次结构是严格嵌套的集合的层次结构集合。层次结构中的每个条目指定一个集合,前一个条目是严格超集,下一个条目是严格子集。例如,所有的矩形都是四边形,但并不是所有的四边形都是矩形,所有的正方形都是矩形,但并不是所有的矩形都是正方形。这种层次结构与部分有序集的更一般的概念是相对照的。

参考文献

链接:
http://www.firstobject.com/dn_markhierarchy.htm.
https://enacademic.com/dic.nsf/enwiki/3928.
https://www.sciencedirect.com/topics/computer-science/containment-hierarchy.

项目联系

本项目的层次结构图如下,组织分级层次结构,内容信息过多,故未在图中展示,每个实体中的属性大致一样,分别为ID、部门号等,各个阶层以上下及形式,一层套一层,形成有组织的层次结构。方便管理。
在这里插入图片描述

配置图(deployment diagram)

名词定义

Deployment diagrams are used to visualize the topology of the physical components of a system, where the software components are deployed.
Deployment diagrams are used to describe the static deployment view of a system. Deployment diagrams consist of nodes and their relationships.
The term Deployment itself describes the purpose of the diagram. Deployment diagrams are used for describing the hardware components, where software components are deployed. Component diagrams and deployment diagrams are closely related.
Component diagrams are used to describe the components and deployment diagrams shows how they are deployed in hardware.
UML is mainly designed to focus on the software artifacts of a system. However, these two diagrams are special diagrams used to focus on software and hardware components.
Most of the UML diagrams are used to handle logical components but deployment diagrams are made to focus on the hardware topology of a system. Deployment diagrams are used by the system engineers.
The purpose of deployment diagrams can be described as:
Visualize the hardware topology of a system
Describe the hardware components used to deploy software components
Describe the runtime processing nodes
部署图用于可视化系统物理组件的拓扑结构,软件组件部署在其中。
部署图用于描述系统的静态部署视图。部署图由节点及其关系组成。
术语部署本身描述了图表的目的。部署图用于描述部署软件组件的硬件组件。 组件图和部署图密切相关。
组件图用于描述组件,部署图显示如何在硬件中部署组件。
UML主要设计用于关注系统的软件工件。
然而,这两个关系图是用于关注软件和硬件组件的特殊关系图。
大多数UML图用于处理逻辑组件,但是部署图主要关注系统的硬件拓扑结构。部署图由系统工程师使用。
部署图的目的可以描述为:
可视化系统的硬件拓扑结构
描述用于部署软件组件的硬件组件
描述运行时处理节点

参考文献

链接:
https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-deployment-diagram/.
https://www.guru99.com/deployment-diagram-uml-example.html.
https://www.tutorialspoint.com/uml/uml_deployment_diagram.htm.

项目联系

部署图用于可视化系统物理组件的拓扑结构,软件组件部署在其中。
部署图用于描述系统的静态部署视图。部署图由节点及其关系组成。
术语部署本身描述了图表的目的。部署图用于描述部署软件组件的硬件组件。 组件图和部署图密切相关。
组件图用于描述组件,部署图显示如何在硬件中部署组件。

动态分类(dynamic classification)

名词定义

Classification refers to the relationship between an object and its type.
Most methods make certain assumptions about this type of relationshipassumptions that are also present in mainstream OO programming languages. These assumptions were questioned by Jim Odell, who felt that they were too restrictive for conceptual modeling. The assumptions are of single, static classification of objects; Odell suggests using multiple, dynamic classification of objects for conceptual models.
In single classification, an object belongs to a single type, which may inherit from supertypes. In multiple classification, an object may be described by several types that are not necessarily connected by inheritance.
Note that multiple classification is different from multiple inheritance. Multiple inheritance says that a type may have many supertypes, but that a single type must be defined for each object. Multiple classification allows multiple types for an object without defining a specific type for the purpose.
分类是指对象与其类型之间的关系。
大多数方法对这种类型的关系进行一定的假设,在主流OO编程语言中也存在这种假设。Jim Odell对这些假设提出了质疑,他认为这些假设对于概念建模来说太有限制了。
假设是单一的、静态的对象分类;Odell建议对概念模型使用多种动态的对象分类。
在单一分类中,一个对象属于单一类型,该类型可以继承超类型。在多重分类中,一个对象可以用几种类型来描述,这些类型不一定通过继承连接起来。
注意,多重分类不同于多重继承。多重继承表示一个类型可以有多个超类型,但必须为每个对象定义单一类型。多重分类允许对象具有多种类型,而无需为此目的定义特定类型。

参考文献

链接:
https://coderanch.com/t/100023/engineering/Reg-multiple-dynamic-classification-UML.
https://coderanch.com/t/98160/engineering/dynamic-classification.
http://etutorials.org/Programming/UML/Chapter+6.+Class+Diagrams+Advanced+Concepts/Multiple+and+Dynamic+Classification/.

项目联系

动态模型中,我们建立了有序列图、状态图还有过程模型,在这里中序列图和状态图都在本报告中都有展示,可以在本报告中查看,这里展示的时过程模型,描述我们项目某个功能的流程,显示了流程的目标、流程中涉及的输入、输出、事件和信息。登记员工用户信息的流程如下,为展示的还有下面的后端流程。
在这里插入图片描述

动态分类(dynamic classification)

名词定义

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 the static keyword. The static keyword 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.
本主题描述x++中的静态类成员。一般来说,静态方法适用于以下情况:
该方法没有理由访问在类中声明的成员变量。
该方法没有理由调用类的任何实例(非静态)方法。
使用static关键字声明静态类成员。static关键字指示系统只创建方法的一个实例,而不管类的实例有多少。这个实例将在整个会话中使用。

参考文献

链接:
https://www.c-sharpcorner.com/article/when-to-use-static-classes-in-c-sharp/.
https://docs.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/dev-ref/xpp-static-classes.
https://www.geeksforgeeks.org/c-sharp-static-class/.

项目联系

静态类是代码编写时应用的情况,项目中的需求分析不涉及实现系统。故与项目很难以联系起来。当然在项目实现的阶段,每个项目可能会应用到的部分。

程序委员会(steering committee)

名词定义

What is a steering committee?A steering committee is a group of people, usually managers.It is formed to oversee and support a project from management level.Committee members are selected based on their stake in the project. In other words: A steering committee should represent the main stakeholders. The customer, the contractor and the departments most affected by your project.Those who sit in the committee are usually not working in the project. It’s the project manager (you) with his team who is implementing the project.
Often, steering committees include C-level executives like CEOs or CFOs. Why? Projects are closely related to a company’s strategy and cost a lot of money. And executives have a keen interest in making sure the money is well spent.
Why do projects need steering?The committee’s job is to steer a project into the right direction.Why is that necessary?Projects often have to make big decisions. Decisions about how a company runs its processes and how teams work together. Those decisions can’t be taken by the project team.Also, a steering board can help resolve issues fast. This is when the project team has tried everything to fix a problem (without success). The committee can use its management force to solve issues and settle conflicts quickly.
什么是督导委员会?指导委员会是一群人,通常是经理。它的成立是为了从管理层面监督和支持一个项目。委员会成员是根据他们在项目中的利害关系挑选出来的。换句话说,指导委员会应该代表主要利益相关者。客户、承包商和受项目影响最大的部门。委员会的成员通常不参与这个项目的工作。执行项目的是项目经理(您)和他的团队。指导委员会通常包括首席执行官或首席财务官等c级高管。为什么?项目与公司的战略密切相关,需要耗费大量资金。高管们对确保这笔钱花在刀刃上有着浓厚的兴趣。
为什么项目需要指导?委员会的工作是将项目引导到正确的方向。为什么这是必要的?项目通常需要做出重大决策。关于公司如何运行流程和团队如何合作的决策。这些决定不能由项目团队做出。此外,一个指导板可以帮助快速解决问题。这是指项目团队尝试了所有方法来修复一个问题(但没有成功)。委员会可以利用其管理力量迅速解决问题和解决冲突。

参考文献

链接:
https://www.tacticalprojectmanager.com/steering-committee/.
https://www.merriam-webster.com/dictionary/steering%20committee.
https://study.com/academy/lesson/steering-committee-definition-purpose-examples.html.

项目联系

指导委员会是一群人,通常是经理。它的成立是为了从管理层面监督和支持一个项目。委员会成员是根据他们在项目中的利害关系挑选出来的。换句话说,指导委员会应该代表主要利益相关者。客户、承包商和受项目影响最大的部门。委员会的成员通常不参与这个项目的工作。执行项目的是项目经理(您)和他的团队。指导委员会通常包括首席执行官或首席财务官等c级高管。

验收测试(acceptance test)

名词定义

What is Acceptance Testing?Once the System Testing process is completed by the testing team and is signed-off, the entire Product/application is handed over to the customer/few users of customers/both, to test for its acceptability i.e., Product/application should be flawless in meeting both the critical and major Business requirements. Also, end-to-end business flows are verified similar as in real-time scenario.
The production-like environment will be the testing environment for Accepting Testing (Usually termed as Staging, Pre-Prod, Fail-Over, UAT environment).This is a black-box testing technique where only the functionality is verified to ensure that the product meets the specified acceptance criteria (no need for design/implementation knowledge).
Why Acceptance Tests?Though System testing has been completed successfully, the Acceptance test is demanded by the customer. Tests conducted here are repetitive, as they would have been covered in System testing.Then, why is this testing is conducted by customers?
This is because:
To gain confidence in the product that is getting released to the market.
To ensure that the product is working in the way it has to.
To ensure that the product matches current market standards and is competitive enough with the other similar products in the market.
什么是验收测试?一旦系统测试过程测试团队完成签订,整个产品/应用程序交给客户/客户的一些用户,为其可接受性测试即产品/应用程序应该是完美的在会议的关键和主要的业务需求。此外,端到端业务流的验证与实时场景类似。
类似生产的环境将是用于接受测试的测试环境(通常称为分段、预prod、故障转移、UAT环境)。这是一种黑盒测试技术,只验证功能,以确保产品满足指定的验收标准(不需要设计/实现知识)。
为什么验收测试?虽然系统测试已经成功完成,但客户仍要求进行验收测试。这里进行的测试是重复的,就像它们在系统测试中所包含的一样。那么,为什么这个测试是由客户进行的呢?
这是因为:
获得信心的产品正在向市场发布。
确保产品在它的方式。
确保产品匹配当前市场标准和足够的竞争在市场上与其他类似产品。

参考文献

链接:
https://www.softwaretestinghelp.com/what-is-acceptance-testing/.
https://softwaretestingfundamentals.com/acceptance-testing/.
https://www.tutorialspoint.com/software_testing_dictionary/acceptance_testing.htm.

项目联系

在开发完成后的阶段,系统将会进行测试,对功能继续测试,对整个系统的性能进行测试,看他是否能够上市,是否基本满足客户的需求,能否正常的工作,对测试出现的bug进行改正,最后进行汇报,重复的测试以获得对即将投放市场的产品的信心。以确保产品按其必须的方式工作。确保产品符合当前市场标准,并与市场上其他同类产品具有足够的竞争力。

元元模型(meta-metamodel)

名词定义

In the English language, the meta refers to a concept as an abstraction to define another concept to describe it, for example, metadata is known as the data that describes or about the data.
Similarly, the meta-model is a model that describes the model “I know that this does not explain anything 😃”
A meta-model is an explicit model of the constructs and rules needed to build specific models within a domain of interest, it is a model at the end but governs how the system or domain of interest will be modeled. Let us explore some definitions and examples in the next sections.
I think the below image should illustrate the concept here, the system we are concerned to build as we agreed before it should be presented by a model that can be viewed in different ways according to the priorities of stakeholders concerns, for example, development view, deployment view, …etc. This model is governed by a meta-model that describes how to build this model
So, meta-meta-modeling is an activity, and this activity produces meta-models, and the meta-meta-model is the language that express the meta-model.
在英语中,元是指一个概念作为一个抽象来定义另一个概念来描述它,例如,元数据被称为描述或关于数据的数据。
同样,元模型是一个描述模型“我知道这不能解释任何事情:)”的模型:)”
元模型是在感兴趣的领域内建立特定模型所需的构造和规则的显式模型,它是一个最终的模型,但控制着系统或感兴趣的领域将如何建模。 让我们在接下来的章节中探讨一些定义和例子。
我认为下面的图像应该说明这里的概念,我们所关心的建立的系统,正如我们之前商定的那样,应该通过一个模型来呈现,该模型可以根据利益相关者关注的优先事项以不同的方式查看,例如开发视图、部署视图等。 该模型由描述如何构建该模型的元模型控制
因此,元元建模是一种活动,这种活动产生元模型,元元模型是表示元模型的语言。

参考文献

链接:
https://www.uml-diagrams.org/uml-meta-models.html.
https://melsatar.blog/2020/01/12/architecture-model-meta-model-and-meta-meta-model/.
https://cs.wmich.edu/~ooda/metamodel.html.

项目联系

元模型定义了描述某一模型的规范,具体来说就是组成模型的元素和元素之间的关系。元模型是相对与模型的概念,离开了模型元模型就没有了意义。在本系统中,公司人事管理系统里面有管理系统还有请假系统,当着两个系统离开的公司人事管理系统,其本身就不知道代表什么管理什么请假什么,就没有了意义。

多重继承(multiple inheritance)

名词定义

As you grow your Python projects and packages, you’ll inevitably want to utilize classes and apply the DRY (don’t-repeat-yourself) principle while doing so. Class inheritance is a fantastic way to create a class based on another class in order to stay DRY. This post will cover more advanced concepts of inheritance, and basic inheritance won’t be covered in depth. We’ll go over a quick intro, but there are much better, detailed introductions out there. Here are some resources to get started: Object-Oriented Programming in Python course & Python Object-Oriented Programming (OOP): Tutorial.
So what is class inheritance? Similarly to genetics, a child class can ‘inherit’ attributes and methods from a parent. Let’s jump right into some code for an example. In the below code block we’ll demonstrate inheritance with a Child class inheriting from a Parent class.
当您开发Python项目和包时,您将不可避免地希望利用类并应用DRY(不要自己重复)原则。 类继承是基于另一个类创建一个类以保持DRY的奇妙方法。 这篇文章将涵盖更先进的继承概念,基本继承不会被深入覆盖。 我们将进行一个快速介绍,但有更好的,详细的介绍。 这里有一些要开始的资源:Python课程中面向对象的编程&Python面向对象编程(OOP):教程。
那么什么是类继承呢? 与遗传学类似,子类可以从父类“继承”属性和方法。 让我们跳入一些代码作为一个例子。 在下面的代码块中,我们将演示从父类继承的Child类的继承。

参考文献

链接:
https://www.geeksforgeeks.org/java-and-multiple-inheritance/.
https://www.datacamp.com/community/tutorials/super-multiple-inheritance-diamond-problem.
https://www.cprogramming.com/tutorial/multiple_inheritance.html.

项目联系

多重继承是代码编写时应用的情况,项目中的需求分析不涉及实现系统。故与项目很难以联系起来。当然在项目实现的阶段,每个项目可能会应用到的部分。

时序图(sequence diagram)

名词定义

What is a sequence diagram in UML?To understand what a sequence diagram is, it’s important to know the role of the Unified Modeling Language, better known as UML. UML is a modeling toolkit that guides the creation and notation of many types of diagrams, including behavior diagrams, interaction diagrams, and structure diagrams.
A sequence diagram is a type of interaction diagram because it describes how—and in what order—a group of objects works together. These diagrams are used by software developers and business professionals to understand requirements for a new system or to document an existing process. Sequence diagrams are sometimes known as event diagrams or event scenarios.
Note that there are two types of sequence diagrams: UML diagrams and code-based diagrams. The latter is sourced from programming code and will not be covered in this guide. Lucidchart’s UML diagramming software is equipped with all the shapes and features you will need to model both.
Sequence diagrams can be useful references for businesses and other organizations. Try drawing a sequence diagram to:
Represent the details of a UML use case.
Model the logic of a sophisticated procedure, function, or operation.
See how objects and components interact with each other to complete a process.
Plan and understand the detailed functionality of an existing or future scenario.
什么是UML中的序列图? 要理解什么是序列图,重要的是要知道统一建模语言(UML)的作用。 UML是一个建模工具包,它指导许多类型的图的创建和表示,包括行为图、交互图和结构图。
序列图是一种交互图,因为它描述了一组对象是如何-以及按什么顺序-一起工作的。 软件开发人员和业务专业人员使用这些图表来理解新系统的需求或记录现有流程。 序列图有时被称为事件图或事件场景。
请注意,序列图有两种类型:UML图和基于代码的图。 后者来源于编程代码,本指南将不涵盖。 Lucidchart的UML图表软件配备了所有的形状和特性,您将需要对两者进行建模。
序列图可以作为企业和其他组织的有用参考。 试画顺序图:
表示UML用例的详细信息。
模拟复杂过程、功能或操作的逻辑。
看看对象和组件如何相互作用以完成一个过程。
规划和理解现有或未来场景的详细功能。

参考文献

链接:
https://www.lucidchart.com/pages/uml-sequence-diagram.
https://www.smartdraw.com/sequence-diagram/.
https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-sequence-diagram/.

项目联系

序列图是一种交互图,因为它描述了一组对象是如何-以及按什么顺序-一起工作的。 软件开发人员和业务专业人员使用这些图表来理解新系统的需求或记录现有流程。 序列图有时被称为事件图或事件场景。
在这里插入图片描述

构件图(component diagram)

名词定义

What is Component Diagram?When modeling large object-oriented systems, it is necessary to break down the system into manageable subsystems. UML component diagrams are used for modeling large systems into smaller subsystems which can be easily managed.
A component is a replaceable and executable piece of a system whose implementation details are hidden. A component provides the set of interfaces that a component realizes or implements. Components also require interfaces to carry out a function.
UML Component diagrams are used to represent different components of a system.In this UML tutorial, will learn:
What is Component Diagram?
Component diagram Notations
What is a component?
Why use Component Diagram?
When to use Component Diagram?
How to draw a component diagram
Example of a component diagram
什么是组件图? 在建模大型面向对象系统时,有必要将系统分解为可管理的子系统。 UML组件图用于将大型系统建模为可以轻松管理的较小的子系统。
组件是系统中可替换和可执行的部分,其实现细节被隐藏。 组件提供组件实现或实现的接口集合。 组件还需要接口来执行功能。
UML组件图用于表示系统的不同组件。 在这个UML教程中,将学习:
什么是组件图?
组件图符号
什么是组件?
为什么要使用组件图?
什么时候使用组件图?
如何绘制构件图
组件图的示例

参考文献

链接:
https://www.guru99.com/component-diagram-uml-example.html.
https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-component-diagram/.
https://www.uml-diagrams.org/component-diagrams.html.

项目联系

时序图(sequence diagram)

名词定义

参考文献

链接:
https://www.lucidchart.com/pages/uml-sequence-diagram.
https://www.smartdraw.com/sequence-diagram/.
https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-sequence-diagram/.

项目联系

组件是系统中可替换和可执行的部分,其实现细节被隐藏。 组件提供组件实现或实现的接口集合。 组件还需要接口来执行功能。
在这里插入图片描述

活动图(Activity diagram)

名词定义

An activity diagram consists of activities, states, and transitions between activities and states.Activity diagrams are another important diagram in UML to describe the dynamic aspects of a system.An activity diagram is basically a flow chart representing the flow from one activity to another.
This activity can be described as an operation of the system.
The control flow is drawn from one operation to another.
This flow can be continuous and branching or concurrently.
Activity diagrams handle all types of flow control by using different elements, such as fork, join, and so on.
Activity diagram description
how to coordinate activities to provide services
some required for operation of the event
the events of a single use case how to relate to each other
how to coordinate a group of cases to create a workflow group
The basic purpose of an activity diagram is similar to the other four types of diagrams.It captures the dynamic nature of the system.The other four diagrams are used to show the message flow from one object to another, while the activity diagram is used to show that the message flow activity from one activity to another is a special operation of the system.
Activity diagrams are used not only to visualize the dynamic characteristics of systems, but also to construct executable systems using rward and reverse engineering techniques.
The only thing missing from the activity diagram is the message section, which does not show any message flows from one activity to another.Activity diagrams are sometimes referred to as flow charts.Although these diagrams look like a flow chart, they are not.It shows a variety of different streams, such as parallel, branching, concurrent, and single streams.The purpose of an activity diagram can be described as drawing the activity flow of the system to describe the sequence of activities from one activity to another.Describes the parallel, branch and concurrent flows of the system.
活动图由活动、状态以及活动和状态之间的转换组成。活动图是UML中另一个重要的图,用于描述系统的动态方面。活动图基本上是表示从一个活动到另一个活动的流程的流程图。该活动可以描述为系统的一项操作。控制流从一个操作绘制到另一个操作。这种流动可以是连续的,分支的,或并发。活动图通过使用不同的元素(如fork、join等)来处理所有类型的流控制。
活动图描述
如何协调活动以提供服务
实现某些操作所需的事件
单个用例中的事件如何相互关联
一组用例如何协调以创建一个工作流组织
活动图的目的活动图的基本目的与其他四种图相似。它捕捉系统的动态特性。其他四个图用于显示从一个对象到另一个对象的消息流,而活动图用于显示从一个活动到另一个活动的消息流活动是系统的一种特殊操作。活动图不仅用于可视化系统的动态特性,而且还用于通过使用rward和反向工程技术构造可执行系统。活动图中唯一缺少的是消息部分它不显示从一个活动到另一个活动的任何消息流。活动图有时被认为是流程图。虽然这些图表看起来像一个流程图,但它们不是。它显示了各种不同的流,如并行、分支、并发和单流。活动图的目的可以描述为画出系统的活动流程描述从一个活动到另一个活动的顺序。描述系统的平行流、分支流和并发流。

参考文献

链接:
http://www.inf.ed.ac.uk/teaching/courses/seoc/2009_2010/notes/10_notes.pdf.
https://www.tutorialspoint.com/uml/uml_activity_diagram.htm.

项目联系

在这里插入图片描述
在这里插入图片描述

数据流图(data flow diagram)

名词定义

What is a data flow diagram?A data flow diagram (DFD) maps out the flow of information for any process or system. It uses defined symbols like rectangles, circles and arrows, plus short text labels, to show data inputs, outputs, storage points and the routes between each destination. Data flowcharts can range from simple, even hand-drawn process overviews, to in-depth, multi-level DFDs that dig progressively deeper into how the data is handled. They can be used to analyze an existing system or model a new one. Like all the best diagrams and charts, a DFD can often visually “say” things that would be hard to explain in words, and they work for both technical and nontechnical audiences, from developer to CEO. That’s why DFDs remain so popular after all these years. While they work well for data flow software and systems, they are less applicable nowadays to visualizing interactive, real-time or database-oriented software or systems.
什么是数据流图? 数据流图(DFD)映射出任何过程或系统的信息流。 它使用定义的符号,如矩形、圆圈和箭头,加上简短的文本标签,以显示数据输入、输出、存储点和每个目的地之间的路由。 数据流程图可以从简单的,甚至手绘的过程概述,到深入的,多层次的DFD,逐步深入地挖掘数据是如何处理的。 它们可以用来分析现有的系统或建模新的系统。 就像所有最好的图表一样,DFD通常可以在视觉上“说出”很难用语言解释的事情,它们为技术和非技术受众工作,从开发人员到首席执行官。 这就是为什么DFDs在这么多年后仍然如此流行的原因。 虽然它们在数据流软件和系统中工作得很好,但现在它们不太适用于可视化交互式、实时或面向数据库的软件或系统。

参考文献

链接:
https://artoftesting.com/data-flow-diagrams-dfd.
https://www.visual-paradigm.com/tutorials/data-flow-diagram-dfd.jsp.
https://www.lucidchart.com/pages/data-flow-diagram.

项目联系

本项目的公司人事管理系统里面的用户登录功能的数据流图,公司员工在系统前端中进行登录,系统根据后端数据库的的数据进行核实还有权限验证,确认用户登陆信息,对该公司员工确认是否登入。数据管理员(即公司人事管理员)在该系统进行权限管理赋予公司层权限以及对公司员工进行用户管理、人事管理等操作。
在这里插入图片描述

商业流程图(Business Process Diagram)

名词定义

What is a business process diagram?A business process diagram is a visual representation of one of your core business processes. It shows on a screen what happens as data passes from one task to the next until it is completed.
Why should you diagram a business process?Nearly everyone has an answer to the question, “How should this process run?”. But if your explanation is only verbal or text-based, you are missing out on a lot.
By creating a visual business process flow diagram, you unlock your mind to actually see the invisible road that your data is travelling.
什么是业务流程图? 业务流程图是您的核心业务流程之一的可视化表示。 它在屏幕上显示当数据从一个任务传递到下一个任务时会发生什么,直到它完成为止。
为什么要绘制业务流程图? 几乎每个人都有一个问题的答案,“这个过程应该如何运行?”。 但如果你的解释只是口头的或文本的,你会错过很多。
通过创建一个可视化的业务流程图,您可以释放您的思想,以实际看到您的数据正在运行的无形道路。

参考文献

链接:
https://kissflow.com/bpm/business-process-diagram/.
https://www.sparxsystems.com/enterprise_architect_user_guide/14.0/guidebooks/tools_ba_bpmn_business_process_diagram.html.

项目联系

通过创建一个可视化的业务流程图,您可以释放您的思想,以实际看到您的数据正在运行的无形道路。
在这里插入图片描述

实体关系图(Entity relationship diagram)

名词定义

An entity-relationship diagram (ERD) is crucial to creating a good database design. It is used as a high-level logical data model, which is useful in developing a conceptual design for databases.
An entity is a real-world item or concept that exists on its own. Entities are equivalent to database tables in a relational database, with each row of the table representing an instance of that entity.
An attribute of an entity is a particular property that describes the entity. A relationship is the association that describes the interaction between entities. Cardinality, in the context of ERD, is the number of instances of one entity that can, or must, be associated with each instance of another entity. In general, there may be one-to-one, one-to-many, or many-to-many relationships.
For example, let us consider two real-world entities, an employee and his department. An employee has attributes such as an employee number, name, department number, etc. Similarly, department number and name can be defined as attributes of a department. A department can interact with many employees, but an employee can belong to only one department, hence there can be a one-to-many relationship, defined between department and employee.
In the actual database, the employee table will have department number as a foreign key, referencing from department table, to enforce the relationship.
实体关系图(ERD)对于创建良好的数据库设计至关重要。 它被用作高级逻辑数据模型,这对于开发数据库的概念设计非常有用。
实体是一个真实世界的项目或概念,存在于它自己。 实体等价于关系数据库中的数据库表,表的每一行表示该实体的实例。
实体的属性是描述实体的特定属性。 关系是描述实体之间相互作用的关联。 基数,在ERD的上下文中,是一个实体的实例数,它可以或必须与另一个实体的每个实例相关联。 一般来说,可能存在一对一、一对多或多对多的关系。
例如,让我们考虑两个现实世界的实体,一个员工和他的部门。 员工具有员工编号、姓名、部门编号等属性。同样,部门编号和名称可以定义为部门的属性。 一个部门可以与许多员工互动,但员工只能属于一个部门,因此可以有一对多的关系。

参考文献

链接:
https://www.sisense.com/glossary/entity-relationship-diagram/.
https://www.edrawsoft.com/entity-relationship-diagrams.html.
https://www.techopedia.com/definition/1200/entity-relationship-diagram-erd.

项目联系

我们的公司人事管理系统,主要有三个实体,公司人事管理员,公司老板和公司员工。
在公司中只能有一个公司老板,和若干个公司员工,公司老板可以管理员工,公司老板和公司员工是一对多的关系。
在这里插入图片描述
在我们系统中公司人事管理员是只有1个,公司人事管理员可以管理公司员工,公司人事管理员和公司员工的关系是一对多。
在这里插入图片描述
公司人事管理员拥有最高高权限,也可以更新公司老板的信息,即公司人事管理员可以管理公司员工,公司人事管理员和公司老板是一对一的关系。
在这里插入图片描述
多实体之间的关系
定义:在两个以上多个实体集之间,当一个实体集与其它实体集之间均(注意是均)存在相同关系,而其它实体集之间均(注意是均)没有关系时,这种关系才称之为多个实体集之间的关系。在以上三个实体中,我们系统主要的三个实体是不存在这种关系的,但是他们三个实体存在的三个实体两两对应的关系。
在这里插入图片描述

总结

读书心得

通过阅读本书了解了需求的意义,作用,以及需求的过程的活动。软件需求的获取和分析是软件系统开发中的一项重要任务,正确获取软件需求是软件技术人员必须掌握的基本技能。本书从软件需求工程的角度出发,以需求开发过程为主线,完整描述了需求获取、需求分析、需求验证、需求规格说明和需求管理等需求工程活动。通过阅读本书在开发者的立场,侧重于实践者的技术与方法,系统全面地介绍了软件需求工程的各项进展,努力促进需求工程领域理论、方法和技术的全面融合应用,以指导需求工程各阶段的系统化实践。需求工程的过程 中需求工程的活动分为 需求获取,需求分析,需求规格说明,需求验证,需求管理。
需求获取是从人、文档或者环境中获取需求的过程。需求分析需求分析主要工作是通过建模来整合各种信息,从而是人们更好地理解问题。需求规格说明获取的需求被编成文档,其中项目背景和范围文档记录业务需求,用户需求文档(或者用例文档)记录用户需求,系统需求被写入需求规格说明记录系统需求。需求验证是为了尽量不给设计,实现,测试,等后继开发活动带来不必要的影响,需求规格说明定义的需求必须正确,准确的反应用户的意图。
需求管理在需求开发结束之后需要一种力量保证需求作用是的持续,稳定和有效发挥,需求管理就是这样一种管理活动。

项目发展建议

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

  • 0
    点赞
  • 1
    评论
  • 0
    收藏
  • 一键三连
    一键三连
  • 扫一扫,分享海报

©️2021 CSDN 皮肤主题: 数字20 设计师:CSDN官方博客 返回首页
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值