A002-185-2510-李海鹏

计算机科学与工程学院实验报告

姓名     :李海鹏	
学号 	:1814080902510	
日期 	:2020年12月19日

一、Excel查找档与项目结合

1.需求基线（Requirement 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.
需求基准是及时的快照，代表已承诺，已审核和已批准的特定产品版本的一组需求。
“发布”可以是完整的交付产品，也可以是产品的任何中期开发增量。当利益相关者“拒绝”需求时，他们真正要做的就是同意并致力于特定的需求基准（无论他们是否以这些术语考虑）。
一旦项目团队建立了需求基准，团队就应遵循务实的变更控制流程，以就添加新请求的功能以及更改或删除现有需求做出良好的业务和技术决策。
变更控制过程与扼杀变更无关。这是为决策者提供信息，使他们能够及时，适当地做出决定，以修改计划的功能。计划的功能是基准。
通常，还给基线指定了唯一的名称，以便所有项目参与者都可以明确地引用它。良好的配置管理实践使团队可以准确地重建任何先前的基准及其所有组件。
个人理解：
需求基线就是把固定的需求都划一根“线”,说明这些需求已经确定下来，添加新的需求或修改原有的需求都必须通过需求变更流程来操作。
在本项目中：
我们项目的需求基线就是用户精确查找，放心实惠购买以及中小型企业商户提升贩卖渠道。

2.软件架构（Architecture）

官方理解：
The organizational structure of a system. An architecturecan be recursively decomposed into parts that interact through interfaces, relationships that connect parts, and constraints for assembling parts. Parts that interact through interfaces include classes, components and subsystems.
个人理解：
软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。先做出一个软件的框架来，然后不断完善软件代码。
在本项目中：
需先搭建的框架为用户注册登录，用户购买支付，商户进货上架这几个框架。

3.属性（Attribute）

官方理解：
A feature within a classifier that describes a range of values that instances of the classifier may hold.
个人理解：
我们日常设计中会有很多的对象，而对象中又有一定的属性，这些属性是来帮助我们描述对象特征和正确运用对象的。
在本项目中：
同样要为数据字典中的ER图实体设计其相应的属性，如：在用户表中我们设计了编号（id），用户名（nickname），密码（password），角色（role），手机号（phone_number）等等属性来为用户设定相应的特征

4.行为（Behavior）

官方理解：
The observable effects of an operation or event, including its results.
个人理解：
就是在用户进行操作，或者触发了一个事件后，可以观察到的效果，也包括其结果。
在本项目中：
很自然地会涉及到很多的行为，例如在用户进行购买的时候，点击购买按钮，会进入订单确认界面，此时系统会生成一个临时订单，这就是一个行为。

5.分类器（Classifier）

官方理解：
A mechanism that describes behavioral and structural features. Classifiers include interfaces, classes, datatypes and components.
个人理解：
这是描述行为和结构特征的机制。并且将行为按照特定的方式进行分类
在本项目中：
比如在商户的功能需求进货以及上架等行为，是专属于商户这一角色的，而普通用户并不能使用这一类的行为，进行这一类的操作

6.协作（Collaboration）

官方理解：
The specification of how an operation or classifier, such as a use case, is realized by a set of classifiers and associations playing specific roles used in a specific way. The collaboration defines an interaction. See: interaction.
个人理解：
一个操作或分类器（如用例）是如何通过一组以特定方式使用的扮演特定角色的分类器和关联来实现的规范。
在本项目中：
在用户这个分类器中，其中的功能是互相协作来完成的，例如下订单功能必须与支付功能相互协作运用，反过来，支付功能也必须由下订单来实现。

7.组件（Component）

官方理解：
A physical, replaceable part of a system that packages implementation and conforms to and provides the realization of a set of interfaces. A component represents a physical piece of implementation of a system, including software code (source, binary or executable) or equivalents such as scripts or command files.
个人理解：
这是系统的一个物理的、可替换的部分，它不能单独运行，要作为系统的一部分来发挥作用，它封装了实现，并符合并提供了一组接口的实现，而且是可以替换的，并且替换不影响整个系统。
在本项目中：
在使用者通过网页浏览器访问电商系统时，这个浏览器便是一个组件，紧接着会请求到我们的Web服务器端进行业务处理，那么Web服务器也是一个组件，同时服务器会访问数据库服务器，进行数据操作，所以数据库也是一个组件。如下图

8.组合（Composition）

官方理解：
A form of aggregation association with strong ownership and coincident lifetime as part of the whole. Parts with nonfixed multiplicity may be created after the composite itself, but once created they live and die with it (i.e., they share lifetimes). Such parts can also be explicitly removed before the death of the composite. Composition may be recursive. Synonym: composite aggregation.
个人理解：
作为整体的一部分，具有强烈的所有权和一致的生命周期的一种聚合关联形式。
在本项目中：
几乎每一处图都用到了组合的形式，因为这能很方便的显示出系统的架构以及各个部分运用的关联关系。

9.模型精化（Model Elaboration）

官方理解：
The process of generating a repository type from a published model. Includes the generation of interfaces and implementations which allows repositories to be instantiated and populated based on, and in compliance with, the model elaborated.
个人理解：
简单地使用模型技术去模拟复杂的系统,势必造成状态空间的爆炸,而无法分析系统性能.使用模型精化可以开发出紧凑的模型,暴露出原模型中子模型的独立性和相互依存关系,为模型的分解求解奠定基础。
在本项目中：
例如在设计搜索功能时，根据已经设计出的简单的搜索过程：输入搜索词–>系统查询搜索词–>返回结果。但是很显然的是，若是当系统拥有了庞大的商品种类数据时，这简单的查询并不能达到很好的效果，因此可以将此模型细化为：选择商品类型–>输入搜索词–>查找搜索词以及与搜索词相似的结果–>返回结果。

10.建模时间（Model Time）

官方理解：
Refers to something that occurs during a modeling phase of the software development process. It includes analysis time and design time. Usage note: When discussing object systems, it is often important to distinguish between modeling time and run-time concerns. See: analysis time, design time. Contrast: run time.
个人理解：
指的是在建模阶段，软件开发过程。 它包括分析时间和设计时间。时间作为标记的一种，一个系统记录下重要阶段进行的时间是很有意义的。
在本项目中：
由于这学期只进行了需求分析与建模，所以只有分析时间，并没有开发时间。

11.多重继承（Multiple Inheritance）

官方理解：
A semantic variation of generalization in which a type may have more than one super type. Contrast: single inheritance.
个人理解：
泛化的一种语义变化，其中一个类型可以有多个超类型。类似于设计语言中的继承，继承的好处是代码重用.哲学上讲事物都是有共性和特性的.把共性函数代码放入到父类中,把特性函数代码放入到子类中,当然是否共性要以参照点的标准。
在本项目中：
也有经常使用到多重继承，例如用户的VIP机制，一个商户可以卖多种物品，一个购物车能放多种商品，等等。多重继承提供了更便捷更灵活的多种可能。

12.对象流状态（Object Flow State）

官方理解：
A state in an activity graph that represents the passing of an
object from the output of actions in one state to the input of
actions in another state.
个人理解：
活动图中的一种状态，表示对象从处于一种状态的操作的输出转换为在另一个状态的行动。
在本项目中：
如我们项目的其中一个活动图中，用户通过点击购买操作，便会从选择商品状态转换成支付状态或者加入购物车二状态。如下图所示：

13.时序图（Sequence Diagram）

官方理解：
A diagram that shows object interactions arranged in time sequence. In particular, it shows the objects participating in the interaction and the sequence of messages exchanged. Unlike a collaboration diagram, a sequence diagram
includes time sequences but does not include object relationships. A sequence diagram can exist in a generic form (describes all possible scenarios) and in an instance form (describes one actual scenario). Sequence diagrams and collaboration diagrams express similar information, but show it in different ways. See: collaboration diagram.
个人理解：
时序图，又称为序列图、循序图，是一种UML交互图。它可以表示用例的行为顺序，当执行一个用例行为时，其中的每条消息对应一个类操作或状态机中引起转换的触发事件。
在本项目中：
我在做本项目的时序图时，会涉及7种元素：角色(Actor)、对象(Object)、生命线(LifeLine)、控制焦点(Activation)、消息(Message)、自关联消息、组合片段。其中前6种是比较常用和重要的元素，剩余的一种组合片段元素不是很常用，但是比较复杂。所以并没有加入组合片段。

14.图（Diagram）

官方理解：
A graphical presentation of a collection of model elements, most often rendered as a connected graph of arcs (relationships) and vertices (other model elements). UML supports the following diagrams: class diagram, object diagram, use case diagram, sequence diagram, collaboration diagram, state diagram, activity diagram, component diagram, and deployment diagram.
个人理解：
模型元素集合的图形表示，图能很方便直观地显示出项目的架构与思想。在统一建模语言（UML）中，可以支持：类图、对象图、用例图、序列图、协作图、状态图、活动图、组件图和部署图。
在本项目中：
同样也需要各种图来描述系统架构，以上几种图均在blog上有记载。地址：
https://blog.csdn.net/weixin_43648733/article/details/109038758

15.域（Domain）

官方理解：
An area of knowledge or activity characterized by a set of concepts and terminology understood by practitioners in that area.
个人理解：
在一个系统中，域的概念是非常重要的，它规定了我们某一操作可涉及的范围，保护不在此域中的其他对象的安全性。
在本项目中：
也对很多种域进行了讨论，其中我个人觉得最重要的是问题域，在本项目里我们所分析得出的问题域为：近年来,互联网技术的迅猛发展使电子商务在世界范围内蓬勃兴起。网上电子商城存在着许多机遇，但是这些机遇存在的同时也面临着问题：电子商务的发展和应用导致中小企业发生根本性的变化。从近年来中小企业应用电子商务的情况来看,往往面临机遇和挑战两个方面的问题:一方面,电子商务先进的技术和开放式的环境,将促使市场结构发生变化,另一方面,由于中小企业的人力、财力、信息技术等实习较弱因此从各方面来说。中小企业开展电子商务所付出的代价也许更大,相对效益而言,成本也许更高。
显然经过这次分析就把我们的设计范围锁定在了互联网以及购物这个域里。

16.枚举（Enumeration）

官方理解：
A list of named values used as the range of a particular attribute type. For example, RGBColor = {red, green, blue}. Boolean is a predefined enumeration with values from the set {false, true}.
个人理解：
用作特定属性类型范围的命名值列表。例如RGBColor = {red, green, blue}. Boolean是一个预定义的枚举，其值来自集合{false，true}。
在本项目中：
有许多地方能够运用枚举，比如在用户信息中，登陆状态Statue的值枚举出来有两个：登录或未登录。一个商品的一级分类ClassifyLevelOne中的值可以枚举为{衣，食，住，其他}。

17.控制焦点（Focus of Control）

官方理解：
A symbol on a sequence diagram that shows the period of time during which an object is performing an action, either directly or through a subordinate procedure.
个人理解：
控制焦点是序列图上的一种符号，表示对象直接或通过一个从属过程执行某个动作的时间段。
在本项目中：
控制焦点是顺序图中表示时间段的符号，在这个时间段内对象将执行相应的操作。用小矩形表示

18.框架（Framework）

官方理解：
A micro-architecture that provides an extensible template
for applications within a specific domain.
个人理解：
为特定域中的应用程序提供可扩展模板的微体系结构。框架是具体项目实施过程中 不断总结提炼出来的库或者模式可以解决80%的重复劳动(类似问题)。
在本项目中：
由于是网络购物类的项目，所以网络上已经有很多比较成型的框架可以给我们借鉴与使用，所以还是比较利于我们后续的分析与开发的。

19.一般化（Generalization）

官方理解：
A taxonomic relationship between a more general element and a more specific element. The more specific element is fully consistent with the more general element and contains additional information. An instance of the more specific element may be used where the more general element is allowed. See: inheritance.
个人理解：
也称泛化，可以理解为更一般的元素和更具体的元素之间的分类关系。更具体的元素与更一般的元素完全一致，并包含附加信息。如果允许使用更一般的元素，则可以使用更具体元素的实例。同时，根据我自身的编程经验，我可以从代码层面理解为是一个类（称为子类、子接口）继承另外的一个类（称为父类、父接口）的功能，并可以增加它自己的新功能的能力，继承是类与类或者接口与接口之间最常见的关系；在Java中此类关系通过关键字extends明确标识，在设计时一般没有争议性。
在本项目中：
这个一般化很类似于继承这个概念，所以运用便自然不用多说。

20.元类（Meta Class）

官方理解：
A class whose instances are classes. Metaclasses are typically used to construct metamodels.
个人理解：
一个实例为类的类。元类通常用于构造元模型。
在本项目中：
元类是构成元模型的很重要的元素，元模型又是模型的模型，所以确定元类很重要，更据我们的需求分析，本项目的元类应该为Meta Class{编号，名，属性}。

21.元模型（Meta Model）

官方理解：
A model that defines the language for expressing a model.
个人理解：
定义用于表达模型的语言的模型。统一建模语言是标准的建模语言，而不是一个标准的开发流程。虽然UML的应用必然以系统的开发流程为背景，但根据我们的经验，不同的组织，不同的应用领域需要不同的开发过程。此我们首先把精力集中在设计通用的元模型上（统一不同方法的语义），其次是建立通用的表示法（提供对这些语义的形象化的表达）。
在本项目中：
所以设计本项目的元模型中，也很有必要先涉及号通用的元模型，所以我参考https://www.researchgate.net/publication/228451480_Design_patterns_for_metamodels 中的元模型设计模式。

22.命名空间（Namespace）

官方理解：
A part of the model in which the names may be defined and used. Within a namespace, each name has a unique meaning. See: name.
个人理解：
模型的一部分，可以在其中定义和使用名称。 在名称空间中，每个名称都有唯一的含义。
在本项目中：
这个对于学过编程的人来说就很容易理解与掌握了，我们可以给需要经常使用或者需要被特殊定义的值一个命名空间，让我们只能使用命名空间里指定的名称，以此来达到特殊标记的效果。本项目中我们还未运用命名空间相关的内容，一是觉得可能没有达到这个程度，二是还没有掌握这个知识点，不会运用。

23.操作（Operation）

官方理解：
A service that can be requested from an object to effect behavior. An operation has a signature, which may restrict the actual parameters that are possible.
个人理解：
可以从对象请求以实现行为的服务。 操作具有署名，这可能会限制可能的实际参数。更简单点理解，就是和我们日常生活中完成一个任务时，每一步所做的东西，那便是操作。
在本项目中：
每当我们设计一个活动图时，里面往往会有许多许多操作，例如：在用户购买到收货，即订单完成这个过程中，相关的操作有：下单，支付，包装，运输，验货，确认订单。

24.参数（Parameter）

官方理解：
The specification of a variable that can be changed, passed, or returned. A parameter may include a name, type, and direction. Parameters are used for operations, messages, and events. Synonyms: formal parameter. Contrast: argument.
个人理解：
可以更改，传递或返回的变量的规范。 参数可以包括名称，类型和方向。 参数用于操作，消息和事件。
在本项目中：
这也是编程中再熟悉不过的东西了，由于我们有许多关联关系，而且再联系时难免要向后者传递一些数据或者向后者作出反应后获得一些数据，所以便有了参数，来方便我们进行相应的操作。

25.参与（Participates）

官方理解：
The connection of a model element to a relationship or to a reified relationship. For example, a class participates in an association, an actor participates in a use case.
个人理解：
模型元素与关系或与关系化关系的连接。例如，一个类参与一个联系，一个参与者参与一个用例。
在本项目中：
这个参与可以说在电子商城系统中也是经常出现的。例如用户参与一个优惠活动，商户参与一个线上商家大会，特定商品参加打折促销。

26.后置条件（Post Condition）

官方理解：
A constraint that must be true at the completion of an operation.
个人理解：
操作完成时必须为true的约束。这个后置条件很有意思，不同于先决条件，这个后置条件可以规定我们进行一个操作后的结果是何种。
在本项目中：
后置条件也可以为我们带来许多方便。例如：在下订单后，支付阶段，支付后的状态必须是true，才能继续执行一次交易的接下来的内容。在商户进货上新后，结果必须徐为true，用户才能够看得到商户上的新品。

27.接收（Reception）

官方理解：
A declaration that a classifier is prepared to react to the receipt of a signal.
个人理解：
声明分类器准备对信号的接收做出反应的声明。这两个字我们日常生活中经常碰到，可是在UML中具体又是什么意思呢？在我看来，可以举一个简单的例子就可以说明：在时序中a调用b的话，b这个就是reception。
在本项目中：
在绘制本项目的时序图时，我们可以从中体会到：在用户创建订单时，会调用上户的创建订单流程。

28.内部过渡（Internal Transition）

官方理解：
A transition signifying a response to an event without changing the state of an object.
个人理解：
表示对事件的响应而未更改对象状态的过渡。这也是字面意思，按照我们日常生活中的正常理解就好了。
在本项目中：
由于内部过渡通常作为状态图的组件之一，所以我特意绘制了一张商户发货的状态图，如下：

29.关联类（Association Class）

官方理解：
A model element that has both association and class properties. An association class can be seen as an association that also has class properties, or as a class that also has association properties.
个人理解：
具有关联和类属性的模型元素。 关联类可以被视为还具有类属性的关联，或者被视为也具有关联属性的类。通俗点讲，可以这样理解，就是在已有的两个类上添加一个能包含他们之间关联信息的一个类，这个类就是关联类。比如：员工和公司两个类中，我们可以添加一个类，里面添加一个属性来存储员工为每个公司工作的时间。可能这时候会有人问：为什么不把这个属性储存在员工中呢？当然可以这么做，可是不好，我们要认清一个现实，当公司改变时，这个储存在员工中的，他为前一个公司的工作时间就会被抹去了。
在本项目中：
我发现在设计这个电子商城系统中，使用关联类是十分有必要的，就拿商品与订单来说，我们可以用一个关联类里的一个属性来存储商品在订单中的数量，值得注意的是，一种商品里，每个订单中的数量都又可能不同，所以用关联类来记录非常好。

30.二元关系（Binary Association）

官方理解：
An association between two classes. A special case of an nary association.
个人理解：
两个类之间的关联。一元协会的特殊情况。简单点理解就是两个事务之间的关系，比如简单的“大于”、“小于”、“等于”，都是建立在二元关系之上的。
在本项目中：
本项目中拥有的二元关系也有很多，而且也符合我们日常生活中的逻辑。

31.动态分类（Dynamic Classification）

官方理解：
A semantic variation of generalization in which an object may change type or role. Contrast: static classification.
个人理解：
泛化的语义变体，其中对象可以更改类型或角色。 与之形成对比的是静态分类。
在本项目中：
实话实说，动态分类这个概念我还是第一次见到，不过经过学习，我觉得可以将这个知识运用到我们的用户分类上，例如原来项目只有用户这一类，通过用户类里的role这个属性来区分是普通用户还是商户还是管理员，这显然是欠妥当的，所以我们可以采用动态分类来解决，即：首先将这三个角色的公共特征抽出取来，比如姓名、手机号、密码等，作为一个People基类，然后再用三个类来继承这一个基类。这就体现了动态分类。如下图

32.主动对象（Active Object）

官方理解：
An object that owns a thread and can initiate control activity. An instance of active class. See: active class, thread
个人理解：
拥有线程并可以启动控件活动的对象。活动类的实例。主动对象是内部拥有自己的控制线程的对象。为了简化异步调用的复杂性，这个模式分离了方法的执行和调用。使用这个模式，一个对象中无论是否有独立的线程，客户从外部访问它时，感觉是一样的。生产者/消费者，读者/写者，这两个应用广泛的模型中，这种策略非常适合。这个模式常用在多线程的，分布式系统中。
在本项目中：
主动对象模式是活动图的一个实例，并且根据他常用于解决多线程问题中，基于本项目是电子商城系统，所以存在高并发，多线程等问题，所以也肯伊运用这个主动对象模式，来提升系统的访问速度，进而提高用户体验。

33.状态机（State Machine）

官方理解：
A behavior that specifies the sequences of states that an object or an interaction goes through during its life in response to events, together with its responses and actions.
个人理解：
这是一种行为，它指定对象或交互在生命中响应事件以及响应和动作所经历的状态序列。状态机是有限状态机的简称，可以用来模拟世界上的大部分事物。简单地说，状态机有三个特性、四个要素。
在本项目中：
本项目中状态机也如上面分析的一样，发生事件(Event)后，根据当前状态(Current State)决定执行的动作(Action)，并设置下一个状态(Next State)。

34.部署图（Deployment Diagram）

官方理解：
A diagram that shows the configuration of run-time processing nodes and the components, processes, and objects that live on them. Components represent run-time manifestations of code units. See: component diagrams.
个人理解：
部署图描述的是系统运行时的结构，展示了硬件的配置及其软件如何部署到网络结构中。一个系统模型只有一个部署图，部署图通常用来帮助理解分布式系统。
在本项目中：
因为本项目还没有最终落实到开发部署服务器环节，所以部署图也就没有实战环节了，所以我更多的是去学习了其相关的概念。
部署图的元素有：
1、结点（Node）
2、结点实例（Node Instance）
3、结点类型（Node Stereotypes）
4、物件（Artifact）
5、连接（Association）
6、结点容器（Node as Container）

35.协作图（Collaboration Diagram）

官方理解：
A diagram that shows interactions organized around the structure of a model, using either classifiers and associations or instances and links. Unlike a sequence diagram, a collaboration diagram shows the relationships among the instances. Sequence diagrams and collaboration diagrams express similar information, but show it in different ways. See: sequence diagram.
个人理解：
该图显示了使用分类器和关联或实例和链接围绕模型结构组织的交互。与序列图不同，协作图显示了实例之间的关系。序列图和协作图表示相似的信息，但是以不同的方式显示它。
在本项目中：
这张图本项目同样没有参与绘制，不过由上面分析可知，此图和时序图表示的信息很相似，所以大概就可以用时序图来替换这个协作图，而这个协作图同样地可以作为参考，下次再进行绘图时可以试着画协作图而省略时序图。

36.容器分层结构（Containment Hierarchy）

官方理解：
A namespace hierarchy consisting of model elements, and the containment relationships that exist between them. A containment hierarchy forms an acyclic graph.
个人理解：
由模型元素及其之间存在的包含关系组成的名称空间层次结构。 包含层次结构形成一个非循环图。
在本项目中：
这个容器分层结构可以说相当的难以理解，我是这样理解的，拿项目的组织模型来说，由于一层传递是绝对不够用的，所以就可以运用分层结构，最终图如下：

37.关联末端（Association End）

官方理解：
The endpoint of an association, which connects the association to a classifier.
个人理解：
关联的端点，将关联连接到分类器。关联末端这个词听起来也有点难懂，但可以这样理解，关联端点由属性表示，每个属性都与端点的类型相关。当一个属性是一个关联端点时，一个或多个值与该关联的另一个端点处的一个或多个实例
在本项目中：
本项目中的关联末端，我可以很自然地想到，例如一个商品的关联末端很有可能是店铺或者消费者。

38.容错（Fault Tolerance）

官方理解：
The capability of a system to continue normal operation despite thepresence of (hardware or software) faults.Fault tolerance may be stated as a quality requirement.个人理解：
即使存在（硬件或软件）故障，系统也能继续正常运行的能力。容错可以说是质量要求。在实际中，容错常常被错误地理解为“尽量保证运行下去”，“尽量不报错，不抛异常”。这种习惯下，经常导致后期bug难以定位。一个模块，如果对一个“错误的输入”可以纠正的，可以仍然产生正确合法的输出。确切来说，这个输入就不应该是错误的，应该视为正常的处理的一个特殊情况。如果可以在一个故障中恢复，这个故障就是你可以容忍；如果对一个故障，可以在牺牲一部分数据的情况下，继续未完成部分的处理，这个故障也是可以容忍的。但是，大多错误是不可以容忍的。错误应该尽早的发现并且暴露出来。
在本项目中：
本项目是一个可多人在线的购物平台，所以拥有一定的容错是必须的。经过分析，网上商城开发应该具有良好的容错性，从而保证交易的完整性。电子商务网页在运行大的程序，都关乎到网上商城的交易情况，所以，在设计商城系统时，要考虑商城的容错性。

39.包图（Package Diagram）

官方理解：
A SysML Package diagram provides a means of visualizing the organization of a complex model into recognizable containers, which helps you to group the structures of the model and define high level relationships between these groupings.
个人理解：
在面向对象的软件开发过程中，类显然是构建整个系统的基本构造块。但是对于庞大的应用系统而言，包含的类是成百上千的，再加上其间“阡陌纵横”的关联关系，多重性等，必然大大超出了人们可以处理的复杂度。因此，引入包这个构造块。包相当于建模元素的容器。通过包可以把类、用例、构件等元素聚集在一起，构成更高层的单位。包图用于构造高级系统元素。软件包用于组织大型系统，其中包含图表，文档和其他关键交付物。
在本项目中：
包图作为一个系统非常重要的一个UML图，当然是我们做分析时要设计好的，所以针对我们的项目，我们设计了相应的包。我们的项目分为数个packge，数据存储在服务器中。而客户端下包含着商品，订单，店铺等。商品包含店铺，销量，评价。而各个packge中还可以再细分。如下图所示：

40.模块定义图（Block Definition Diagram）

官方理解：
A Block defines a collection of features used to describe a system, subsystem, component or other engineering object of interest. These features can include both structural and behavioral features, such as properties, operations and receptions, that represent the state of the system and the behavior that the system might exhibit.
个人理解：
块定义图的目的是指定用于控制对象，数据对象和接口对象的系统静态结构。正确应用后，框图可以递归地缩放，并且可以在数学上（参数上）模拟。SysML中的块定义图定义了块的功能以及块之间的关系，例如关联，通用性和依赖性。它根据属性和操作以及诸如系统层次结构或系统分类树之类的关系来捕获“块”的定义。从模型或包创建块定义图：右键单击模型或包，指向新建，指向SysML，指向结构，然后单击块定义图。
在本项目中：
我们的项目是一个父系统——电子商城系统，下面包含支付、智能搜索，平台活动、商品管理以及登录子系统。具体功能图如下：

二、读书心得

这一学期我所学的《需求工程–软件建模与分析》这门课程，可以说是一门对我有足够冲击力以及影响力的课程了。首先焦点就在于对于我个人观念的一个改变。在学习这门课程之前，我所认为的软件行业就仅仅是以编码为主的，但是在学习完这门课程后，我就明白了，编码其实只占一个软件开发的30%左右，真正需要花时间的是需求分析阶段。因为在软件工程中，需求分析指的是在建立一个新的或改变一个现存的电脑系统时描写新系统的目的、范围、定义和功能时所要做的所有的工作。需求分析是软件工程中的一个关键过程。在这个过程中，系统分析员和软件工程师确定顾客的需要。只有在确定了这些需要后他们才能够分析和寻求新系统的解决方法。
在软件工程的历史中，很长时间里人们一直认为需求分析是整个软件工程中最简单的一个步骤，但在过去十年中越来越多的人认识到它是整个过程中最关键的一个过程。假如在需求分析时分析者们未能正确地认识到顾客的需要的话，那么最后的软件实际上不可能达到顾客的需要，或者软件无法在规定的时间里完工。
在绪论第一章中的内容就是让我了解需求工程的来源以及重要性。就如上面所说的一样。在第二章中，我学习了需求的基础，在这一章中，我明白了需求的定义，这里引用IEEE的需求定义：
①用户为了解决问题或达到某些目标所需要的条件或能力；
②系统或系统部件为了满足合同、标准、规范或其他正式文档所规定的需求而需要具备的条件或能力；
③对①或②中的一个条件或一种能力的文档化表述
其次我还明确了一点，满足需求就是解决问题，需求和问题都有层次性。到了第三章，就到了很重要的需求工程过程了，主要讲述了一个需求工程活动包括哪几个方面。
到了第二部分的需求获取，可以说是全书最重要的部分了，老师特地给我们讲了需求获取活动中的四个方框以及四个圆圈，可以说这八个点是需求获取活动流程中的最重要的几点了。让我明白需求获取是很有逻辑性的，很有顺序性的。首先由问题域以及涉众分析并确定项目前景与硬数据采样，然后根据系统环境展开用户需求获取，从而从诸多需求中抽取用户需求。
还有很重要的一个方面就是学习UML建模，在学习UML这门课之前，我一直心底有一个疑问，那就是我们和那些所谓的程序员速成班培训出来的程序员到底有什么差别，都是写代码，那我们在大学里学习的意义是什么呢，直到我学习了UML这门课。我才知道写代码并没有想象中的那么简单，对于同一个功能，肯定有着多种不同的实现方法，而这些方法也肯定有优劣之分。我们之所以不像外面那样的培训班一样速成，是因为我们需要锻炼自己去写出高质量的代码，我觉得这就是我们学习的意义。
其实在上UML课之前，我以为UML跟C++和java一样是一门编程语言，直到经过老师的介绍，我才知道UML的全称是Unified Modeling Language，他不同于C++,java这些编程语言，他是统一建模语言。UML是一种用于可视化描述系统，具有广泛用途的建模语言。作为一种标准化的图形语言，在软件工业中被用于软件系统部件的具体化，可视化，结构化描述以及撰写文档，同样在商业模型中也得到应用。
UML虽然不是一门程序设计语言，但他的重要性是不可忽视的。他的重要性主要体现在：使复杂的软件设计更为简单，也能够实现像OOP（面向对象编程）这一类被广泛应用的概念；用理解起来可能更容易的图来描述，避免了大量的文字；使表达和交流概念或系统结构变得更容易；在一张图中就能够描绘出整个系统；程序员实用类图来描述实际需求时，可让问题更加清晰明了，实现起来更容易。
很多人或许会说直接写代码要比画图分析什么的快多了，但我认为UML在分析和设计阶段十分重要。在学完职责分配原则和了解过一些设计模式过后，我更加坚定了我的想法。或许对于一个小项目来说，实现的方式有很多种，无论是哪一种，可能会有人觉得只要能够实现功能就是可用的，就是好的。但如果是一个比较庞大的项目呢？如果在具体写代码时某个类的职责过于庞杂，那么必定会给系统带来很大的压力。或者说每个类之间的关系特别复杂，那么当后续需要更改某个类的时候，必定会影响到其他的类，带来十分高昂的维护成本。而GRASP的九个原则：信息专家原则，创造者原则，低耦合原则，高内聚原则，控制器原则，多态原则，纯虚构，中介原则，受保护变量原则可以在一点程度上很有效地解决这些问题。

三、项目发展建议

由于这是我们第一次进行系统地学习需求分析，第一次对一个项目进行需求获取与建模，所以当前的1.0版本的需求分析肯定会存在不足，所以在后续学习发展中这个项目的需求分析一定还有值得改进的地方。
比如说，本项目在用户需求方面应该下更大的功夫，这可以体现在
①用户的观感需求，观感需求一些与产品的用户界面相关的需求描述，从而使自己设计的产品更符合用户的观感体验。
②易用性需求，这主要体现在易于使用描述如何构建符合最终用户期望的产品以及学习的容易程序学习使用该产品应该多容易的说明。通常是有学习时间来衡量。
③性能要求，这个需要从速度需求明确完成特定任务需要的时间，这常常指响应时间。 ④安全性的需求，对可能造成人身伤害、财产损失和环境破坏所考虑到的风险进行量化描述。特别是本项目涉及到金钱货物的交易，因此安全性需求显得尤为重要
接着就是注重规范软件需求分析的方法，这里我打算采用原型方法，分以下几点阐述：
传统的软件工程方法强调自顶向下分阶段开发，要求在进入实际开发期之前必须预先对需求严格定义。但实践表明，在系统建立起来之前很难紧紧依靠分析就确定出一套完整、一致、有效的应用需求，并且这种预先定义的策略更不能适应用户需求不断变化的情况。由此，原型法应运而生，它一反传统的自顶向下的开发模式，是目前较流行的使用开发模式。
原型的概念，原型最早使用在制造业和机械产品设计中，先做出产品的基本模型，然后进行完善和改进，最后得到符合要求的产品。在软件工程中，原型是指要开发的软件系统的原始模型，是软件早期一个可运行的版本，它反映最终系统的某些重要特性(如软件界面与布局、功能等)。在获得一组最基本的需求说明后，通过分析构造出一个小型的简约软件系统，满足用户的基本要求，然后不断演化得到较高质量的产品。原型法克服了传统软件生命周期法的一些弊端，具有快速灵活、交互式等特点，方法核心是用交互、快速建立起来的原型取代了不太明确的需求规格说明，用户通过在计算机上实际运行和试用原型系统得到亲身感受并受到启发，通过反应和评价向开发者提供真实的反馈意见。然后开发者根据用户的意见对原型加以改进，通过“原型构造-试用运行-评价反馈-分析修改”的多次反复,从而提高最终产品的质量。
原型分类，由于建立原型的目的不同，实现原型的途径也有所不同，通常有以下三种类型：(1)探索型。这种原型目的是要弄清除客户对目标系统的要求，确定所希望的特性，并探讨多种方案的可行性。(2)实验性。这种原型用于大规模开发和实现之前，考核方案是否合适，规格说明是否可靠。(3)进化型。这种原型的目的不在于改进规格说明，而是将系统建造得容易处理变化，在改进原型的过程中，逐步将原型进化成最终系统。
原型建立技术，(1)可执行规格说明。它是基于需求规格说明的一种自动化技术，使用这种方法，人们可以直接观察用语言规定的任何系统的功能和行为。(2)基于脚本的设计。脚本是用户界面的原型。一个脚本用来模拟在系统运行期间用户经历的事件。它提供了输入——处理——输出的屏幕格式和有关对话的模型。因此，软件开发者能够给用户显示系统的逼真的视图，使用户得以判断是否符合他的意图。(3)自动程序设计在程序自动生成环境的支持下，利用计算机实现软件的开发。它可以自动地或半自动地把用户的非过程式问题规格说明转换为某种高级语言程序。(4)专用语言。专用语言是应用领域的模型化语言。在原型开发中使用专用语言，可方便用户和软件开发者对系统特性进行交流。(5)可复用的软件。利用可复用的模块，通过适当的组合，构造的原型系统。为了快速地构造原型，这些模块首先必须有简单而清晰的界面;其次它们应当尽量不依赖其它的模块或数据结构;最后，它们应具有一些通用的功能。(6)简化假设。 简化假设使设计者迅速得到一个简化的系统。尽管这些假设可能实际上并不能成立，但它们可以使开发者的注意力集中在一些主要的方面。在修改一个文件时，可以假设这个文件确实存在。 在存取文件时，待存取的记录总是存在。一旦计划中的系统满足用户所有的要求，就可以撤消这些假设，并追加一些细节。
原型分析优点，(1)增进软件开发者和用户对需求的理解，使比较含糊的具有不确定性的软件需求(主要功能性的需求)明确化。(2)软件原型化方法提供了一种有力的学习手段。(3)使用原型化方法，可以容易地确定系统的性能，确认系统主要服务的可应用性，确认系统设计的可行性，确认系统最终作为产品。
最后便是让本项目的需求能够应对在开发项目过程中，用户随时会提出一些新的需求，要求开发人员解决，这些需求的提出，有时在开发阶段中有时在开发阶段后。这种在需求分析的两个相邻子阶段中，或者在迭代周期的需求分析中，后一段或周期的需求分析结果与前一次不一致，这就是需求的变更。产生需求变更的原因主要有以下几个方面：(1)在需求分析阶段，开发人员与用户的沟通不够。在需求分析阶段，开发方与用户没有很好的交流，开发方就根据用户提供的大概信息，自己推导出用户的需求。通过这种需求分析得出的需求往往会和用户的实际需求相差甚远，导致用户提出更改需求。(2)项目的实施周期过长。随着时间的推移，用户对整个系统的了解也越来越深入。他们会对模块的界面、功能和性能方面提出更高更多的要求。(3)技术更新过快。由于技术的快速更新， 企业可能引进一些新的设备， 而这些设备可能就会与我们的目标系统有直接的关系， 由于这一变化可能发生在解决用户原先问题之前或者之中， 那么开发人员不得不加入这一新的需求。
为了尽可能地避免发生需求变更，以及保证需求分析的高稳定性，采用以下方法：
需求评审和设立需求基线。为了让开发方详细了解用户的需求，让不同人员从不同的角度对需求进行验证，作为需求的提出者， 在需求评审过程中，用户往往能提出许多有价值的意见。同时，也是用户对需求进行最后确认的机会，可以有效减少需求变更的发生。需求在通过正式评审和批准之后，应该确定需求基线，进一步的需求变更将在此基线的基础上，依照项目定义的变更过程进行。设置需求基线可以将变更引起的麻烦减至最小。

四、参考资料

Airili的个人博客：
https://blog.csdn.net/weixin_43648733

百度百科：
https://baike.baidu.com/

维基百科：
https://bk.tw.lvfukeji.com/wiki/Wikipedia:%E9%A6%96%E9%A1%B5

《需求工程–软件建模与分析》（第2版）
骆斌 主编

元模型的设计模式
https://www.researchgate.net/publication/228451480_Design_patterns_for_metamodels

定义和实施需求曲线
https://www.jamasoftware.com/blog/defining-requirement-baseline/