服装店销售管理软件模型

服装店销售管理软件模型是对软件在各开发阶段本质特性的描述。软件模型包括领域模型、需求模型、设计模型、实现模型和测试模型等。软件建模过程是伴随着软件开发的由粗到细、逐步求精的过程。软件建模语言是描述软件模型的规则符号集。UML是一种统一软件建模语言，具有严密的语法、语义规范。UML采用一组图形符号来描述软件模型，并具有简单、直观、规范的特点。教学要求①掌握软件模型的概念。②掌握软件建模过程。③掌握统一建模语言UML。重点和难点①软件模型的概念。②统一建模语言UML。

4．1模型
模型是对现实的抽象或模拟，是对现实系统的本质特征的一种抽象、简化和类比式的描述。模型不包括现实系统的全部特征，但它要反映现实系统的本质特征。现实系统的复杂性和内隐性，使得人们难于直接认识和把握。为了使得能够人们直观而简单地认识和把握现实系统，需要借助于模型。例如，地图是地形地貌的模型，人们通过地图可以非常直观地了解地形地貌。有些现实系统具有非常复杂的内部结构，人们在生产和加工这些系统时，就需要通过模型来展现这些现实系统的结构和构成。例如，在生产汽车的过程中，需要预先设计出反映汽车结构的设计图纸，然后生产车间再根据设计图纸组织生产，设计图纸就是所要生产的汽车的模型。
模型对现实系统是一种抽象、简化和本质性反映。模型一定不是现实系统，模型也比现实系统简单，比现实系统还复杂的模型就失去了模型的意义。所谓好模型就是既能够反映现实系统的本质特征，又尽量地简化，同时具有简单直观的表示形式。模型具有不同的抽象度，模型的抽象程度越高，距现实系统的距离就越远，模型所考虑的因素也就越少。
从抽象程度，可以把模型分为概念模型、逻辑模型和物理模型。概念模型是人们根据所要达到的目标和人们以往的知识和经验，构造出来的一种系统雏形。它是对所描述系统的主要特征的一种概括性描述。逻辑模型是在概念模型的基础上，从原理上证明是合理可行的系统，它考虑了系统的目标、结构、功能和实现的合理性。但逻辑模型一般不考虑实现的细节。物理模型是在逻辑模型的基础上，充分考虑环境，并对细节都做了精心设计的实在模型。
建立模型的过程被称为建模。模型对现实系统的反映不是简单地复制和照搬，而是对现实系统的抽象。所以建立模型的过程需要认识现实系统的本质特征，并对现实系统进行抽象和概括，然后以科学和直观的形式把模型表现出来。建模的过程是一个反复、逐步求精的过程。图4．1说明了建模的过程。
软件属于智能性系统，在软件中蕴藏着大量的信息、知识、方法和技术。软件无论是在开发过程中，还是在开发成功之后，都不具备其他简单物质系统的形态外显性。软件这种深刻的包藏性，给软件的开发带来了极大的困难，使得在整个软件开发过程中，人们对它难以把握和描述。为了工程化并有效地开发软件，人们除了寻求有效的开发方法，严密地组织开发过程之外，还需要在开发的各个阶段，以某种有效的形式，把软件描述和表现出来，这样开发人员才能够有针对性地进行交流和讨论。我们把通过确定的形式，对软件本质特性的描述称为软件建模，而所描述的结果称为软件模型。
软件模型是对软件在各个开发阶段的本质特性的描述，它要反映软件系统的形成过程。因此，软件模型应该具有多种形式，一般包括领域模型、需求模型、设计模型、实现模型和测试模型等。这些模型反映了人们对软件认识的不同方面和深入化程度。例如，需求模型描述软件的外在特性，而逻辑模型贝0是从软件内部，对软件构成要素和结构的抽象描述。
图4—2表示软件模型的构成，带小凸起框的矩形框是UML中的一个包，在此用来表示模型和子模型，带箭头的虚线表示依赖关系，表示上面这个模型依赖下面这些子模型。

4．2．2服装店销售管理软件建模过程
软件建模过程伴随着软件的开发过程。软件有多种子模型，因此，在软件开发的不同阶段需要有侧重和有针对性地建立适合对应阶段特点的子模型。软件各子模型的建立不是顺序过程，而是迭代和重复的过程。在一个时期可能同时要建立多个子模型。软件建模过程是一个由粗到细、逐步求精的过程。软件建模过程可以由图4—3直观地反映出来。

4．2．3软件建模语言
软件建模语言是描述软件模型的规则符号集。软件建模语言与软件开发方法和开发过程有关，不同的开发过程规定了不同的开发步骤和开发工作，不同的开发方法规定了不同的建模语言。例如，结构化方法就采用数据流图来描述系统的需求和功能，用结构图描述系统的软件结构。在1995年以前，面向对象方法就有五十多种，每一种方法的建模语言都不一样。建模语言的不统一，给软件开发造成了极大的困难和混乱。针对这一问题，Rational公司对各种建模语言进行了分析归纳，在此基础上提出了适应于所有软件开发的统一建模语言UML。UML已经成为软件建模语言的事实标准。本书主要采用UML作为软件的建模语言。

4．3统一建模语言UML
4．3．1概述
1．UML概念和特点
UML(unifiedmodelinglanguage)作为一种统一的软件建模语言，具有广泛的建模能力。UML是在消化、吸收、提炼至今存在的所有软件建模语言的基础上提出的，是软件建模语言的集大成者。UML还突破了软件的限制，广泛吸收了其他领域事物的建模方法，并根据事物建模的一般原理，结合软件的特点，具有坚实的理论基础和广泛性。UML不只可以用于软件建模，还可以用于其他领域的建模工作。
UML立足于对事物实体、事物性质、事物关系、事物结构、事物状态、事物动态变化过程的全程描述和反映。UML可以从不同角度和方面描述人们所观察到的软件视图，也可以描述在不同开发阶段中的软件的形态。UML可以建立领域模型、需求模型、设计模型、实现模型和测试模型等。
作为一种建模语言，UML有严密的语法、语义规范。UML建立在元模型理论基础之上，包括四层元模型结构，分别是基元模型、元模型、模型和用户对象。四层结构层层抽象，下一层是上一层的实例。UML中的所有概念和要素均有严格的语义定义。
UML采用一组图形符号来描述软件模型，这些图形符号具有简单、直观、规范的特点。所描述的软件模型，可以直观地理解和阅读，开发人员学习和掌握起来比较简单。由于其规范性，所以能够保证模型的准确、一致。
2．UML的基本内容
作为一种对客观系统的建模语言，UML提供了描述事物实体、性质、结构、功能、行为、状态、关系的建模元素，并通过一组图来描述由建模元素所构成的多种模型。UML的建模元素包括基本建模元素、关系元素和图三大类，见图4—4。
(1)基本建模元素
基本建模元素可以分为结构、行为、组织、注释四类。结构类建模元素用来反映事物和实体，包括用例、类、接口、构件、协作和节点等；行为类建模元素反映事物之间的交互过程和状态变化，这类建模元素有交互图和状态图；组织类建模元素用来描述通过一组模型元素反映的模型、子系统、框架等的组织，包括包、模型、子系统、框架等；注释类建模元素用来在建模过程中对模型的注释说明。
关系元素用来反映模型元素之间的关系，共包括关联关系、泛化关系、依赖关系和实现关系。
通过基本建模元素构成图来表示软件模型，有用例图、类图、对象图、顺序图、协作图、状态图、活动图、构件图、实施图等。UML共定义了两类九种图形来表示各种模型，见图4-5。

4．3．2用例图
1．用例动态行为
用例(usecase)是使用者与系统之间，为达到确定目的所进行的一次交互过程。使用者向系统提供某些交互要求，系统向使用者反馈所要的结果。用例是系统功能需求的反映。
可以用一段自然语言描述一个用例。例如，图4-6给出了“顾客网上购物”的用例描述。
顾客通过网络浏览商品目录，找出所要的商品。需要用信用卡与商店结算。顾客给出自己的信用卡信息和送货地址。商店检查信用卡的有效性。当信用卡通过检查后，商店确定购货业务成交，商店确定发货时间，并给销售部发出发货通知。然后商店把发货信息通过电予郢件发送给顾客。
2．活动者
活动者(actor)表示与系统进行交互的外部实体。活动者通过运行系统的用例，来获得系统所提供的一项服务。活动者用用例图中的小人来表示，下面标上活动者的名称。例如，图4—8中的“管理者”和“借阅者”等。
活动者可以是系统的使用者，外部与系统存在信息交换关系的设备，也可以是与系统交互信息的外部其他系统。
3．用例图
用例图(usecasediagram)用来描述软件系统向一组活动者提供的一组相关的功能。在一个用例图中，有一个或多个活动者与一个或多个用例相互关联。一个系统的全部用例图构成该系统的需求模型。图4—8是图书馆借阅管理的用例图。在用例图中，小人表示与系统进行交互的活动者。椭圆表示用例，椭圆中填写用例名。活动者与用例之间的连线表示活动者与系统之间的交互关系。用例之间存在着泛化和包含关系。
用例图反映使用者和系统的交互过程。使用者处于系统边界之外，用例图描述系统能够给使用者提供的功能。由系统边界把系统和使用者划分开来。系统边界由包图(下面介绍)来表示。
一个用例图反映具有一组相关功能的用例。用例图也可以分层分解和细化。上层用例图中的用例一般描述抽象度较高的系统功能，为了更清楚地反映用例所描述的功能，可以把一个用例分解成为一个下层的用例图。下层用例图是对上层用例的分解。用例图可以逐层分解。
用例除了与活动者存在关联关系之外，用例之间也可能存在的泛化关系和包含关系。
(1)泛化关系
泛化表示一般与特殊的关系。当两个用例之间存在着一般与特殊关系时，用泛化关系来表示。例如，图4-9中的“收费”和“道路收费”之间是一般和特殊的关系，这两个用例之间存在泛化关系。
除了用例之间存在泛化关系外，活动者之间也可能存在泛化关系。例如，“客户”与“团体客户”和“个体客户”之间就存在泛化关系，见图4—10。
(2)包含关系
包含关系是描述一个用例的行为包含另外一个用例的行为的用例之间的依赖关系。包含关系用带箭头的虚线来表示，并在虚线上标注<<include>>。图4—1l描述了“售货”与“收款”两个用例之间存在包含关系。
(3)扩展关系
扩展关系是描述一个用例的行为可能有条件地使用到另外一个用例的行为。扩展关系用带箭头的虚线来表示，在虚线上标注<<extend>>。图4．12描述了“售货”与“收款”两个用例之间存在扩展关系。

4．3．3类图与对象图
1．类图图
类图(classdiagram)用来描述组成系统的静态结构。一个类图由一组类以及它们之间的关系构成。类(class)描述事物以及事物的静态和动态性质，类的关系反映事物之间的联系，主要有关联关系、泛化关系、依赖关系和实现关系等。
2．对象图
对象图描述类图在某一时刻，对象相互之间的链接关系，相当于类图在某时刻的一个快照。因为对象具有生命周期，不同时刻类图中的对象并不相同，因此，同一幅类图会有不同的对象图。在描述系统的静态结构时，并不一定要绘制对象图，只有当需要反映某一时刻系统中对象相互之间的链接关系时，才有必要画出对象图。
对象图中的节点是对象，节点用矩形框表示。对象名的格式为：对象名：类名，例如，C1：订单，省略对象名的对象被称为匿名对象，例如，：订单。

4．3．4交互图
1．概述
交互图描述一组事物对象合作完成一项工作时，相互之间消息的交互过程。交互图反映在系统运行过程中，对象之间的动态联系活动，以帮助人们理解和把握系统内部各对象之间的动态协作关系。
交互图分为顺序图和协作图两种形式。顺序图反映各对象之间的消息传送顺序，重点描述对象之间交互的时序关系。协作图反映为完成一件工作所参与的对象，以及对象之间的消息联系。
2．顺序图
顺序图反映各对象之间消息传送的时序关系。顺序图由对象、对象生命线、对象激活期和对象之间传输的消息等图形要素构成，图4．15是一个订货管理的工作的顺序图。
在顺序图中，参与交互活动的对象用矩形框表示。在框中标注对象名，也可以采用匿名对象。对象的生命线表示对象的存活期，在对象下面用一条虚线表示。在对象生命线上的窄条为对象的激活期，表示对象在生存期内处在激活状态。消息是对象之间的通信信息，用带箭头的线段表示一个对象传送给另外一个对象的消息。在消息上要注明消息名。虚线软件工程概论表示返回的消息。
3．协作图
协作图描述一组对象之间消息交互的协作关系。在协作图中，对象作为节点，存在消息交互关系的对象之间用关联线连接，并在关联线上标注交互的消息名。
协作图与顺序图是等价的，包含的信息量相同，其差别是描述的角度不同。顺序图侧重反映对象之间的消息交互时序，协作图重点描述对象之间的消息交互结构。

4．3．5状态图
状态图描述事物对象在其生存周期中所具有的各种状态和关系，以及因事件激励导致的状态变化和关系。图4—17是书店图书的状态图。书店的图书要经过订购、库存、待销售、售出或报废等状态。
状态图中的节点是事物所处的状态。实心圆表示初始状态，带圆圈的实心圆表示结束状态。一幅状态图中一般有一个初始状态。箭头表示状态的切换，在箭头上标注状态切换的激发条件。

4．3．6活动图
活动图用来描述事物发展变化的过程。活动图可以描述业务流程、工作流程、类中的操作流程等。图4．18是反映书店图书入库业务流程的活动图。采购员凭到货通知单到车站或邮局领取图书，并把到货的图书与图书订单进行核对，检查是否存在偏差。如果有偏差，则与运输部门或邮局进行联系；如果没有偏差，则领回图书。采购员领回图书之后，填写图书入库单，然后持入库单到书库入库，库管员核对图书与入库单。如果发现有误，则请采购员修改入库单；如果核对无误，库管员登记入库账，并把入库图书收库，入库过程结束。在活动图中，要表示出活动的开始和结束。圆形框表示活动，菱形框表示检查。用虚线隔开的两个部分称为泳道，表示两个实体所进行的活动。

4．3．7构件图
构件可以是一段源程序代码、一个文本文件、一个二进制文件或一个可执行文件。基于构件开发的软件系统，是由多个软件构件按照确定的关系构成的。构件图用来描述构成软件系统的软构件以及它们之间的相互依赖关系。
在构件图中，带两个小框的矩形框表示构件。构件之间的带箭头的虚线表示构件之间的依赖关系。图4一19是一个构件图的例子。该图包括售书界面、售书处理、退书处理、图书浏览和书务数据库五个构件。

4．3．8配置图
配置图用来描述系统中计算结点的拓扑结构，反映系统物理节点的分布，图4．20是配置图的例子。

4．3．9包图
1．包的含义
包是模型的组织单位。一个复杂的系统模型需要分解成为多个部分，每一部分用包来表示。包是UML的一种模型元素，可以用来表示模型、子模型、系统、子系统等系统模型的单位。包表示为图4．21的形式。如果包中的内容被隐藏，包名就注在包的中间：如果包表示的内容要展现，包名写在上面的小框中。
2．包间的关系
包与包之间可以存在依赖关系。图4—22描述教学管理系统三个子系统中包之间的依赖关系。

本章小结
模型是对现实的抽象或模拟，是对现实系统的本质特征的一种抽象、简化和类比式的描述。模型不包括现实系统的全部特征，但它反映现实系统的本质特征。软件模型是对软件在各开发阶段本质特性的描述，它要反映软件的形成过程。服装店销售管理软件模型一般包括领域模型、需求模型、设计模型、实现模型和测试模型等。软件建模过程是伴随着软件的开发由粗到细、逐步求精的过程。
软件建模语言是描述软件模型的规则符号集。UML是一种统一建模语言，具有严密的语法、语义规范。UML的建模元素包括基本建模元素、关系元素和图三大类。基本建模元素可以分为结构、行为、组织、注释四类。结构类建模元素用来反映事物和描述实体，包括用例、类、接口、构件、协作和节点等；行为类建模元素反映事物之间的交互过程和状态变化，这类建模元素有交互图和状态图；组织类建模元素用来描述通过一组模型元素反映的模型、子系统、框架等的组织，包括包、模型、子系统、框架等；注释类建模元素用来在建模过程中对模型注释说明。关系元素用来反映模型元素之间的关系，包括关联关系、泛化关系、依赖关系、实现关系。UML有用例图、类图、对象图、顺序图、协作图、状态图、活动图、构件图、实施图等。

文章来源：秘奥软件网，中小企业信息化领跑者！全国咨询热线：400-9908-527_www.misall.com