设计模式大作业-服装管理系统(包调试成功)

课 程 设 计 说 明 书

课程名称:软件设计模式与体系结构

设计题目:服装管理系统

小组类别:

完成时间:

目录

一、 概述11

1.1项目背景11

1.2项目目的22

1.3功能设计22

二、 总体设计44

2.1系统架构图44

2.2接口设计66

三、 详细设计88

3.1服装价格计算模块设计88

3.1.1工厂模式99

3.1.2单例模式1212

3.1.3策略模式1414

3.1.4装饰模式1616

3.2服装信息管理模块的设计2020

3.2.1模板模式2121

  1. 概述
    1.1项目背景
    近年来,随着移动互联网的快速发展,服装商务越来越受到网民们的欢迎,服装商务对国名经济的发展也起着越来越重要的作用。简单的流程、便捷可靠的支付方式、快捷畅通的物流快递、安全的信息保护都使得服装商务越来越赢得民众的青睐。现今,大量的计算机技术应用于商业领域,包括软件技术、网络技术、硬件技术等。越来越多的企业使用计算机来开展业务、销售、购买和宣传各种服装产品。各种商业系统和软件已经解放了企业的双手,并使企业能够最大限度地获得利益。随着计算机技术的发展和应用领域的不断扩宽,软件需求迅速增长,软件系统也空前庞大和复杂,“软件危机”逐渐显现。所谓软件危机主要包括两个方面:如何开发软件,满足日益增长的软件需求;如何维护数量不断膨胀的软件。软件危机促使人们开始对软件特性进行更深入的研究,改变了人们早期对软件的不正确的看法。现在人们普遍认为优秀的程序除了功能正确,性能优良之外还应该容易看懂、容易使用、容易修改和扩充。
    因此,计算机技术在服装商业领域占有非常重要的地位,而软件设计模式与体系结构作为软件项目开发的必要设计,我们小组采用多种体系结构和设计模式,结合各自特点及优势,初步开发了移动式服装管理系统,此系统包含服装价格计算以及服装信息管理等两大功能模块。
    1.2项目目的
    传统的服装管理依靠大量人力、物力,消耗时间且效率低下,已无法满足现代社会人们的大量服装需求。本项目通过结合传统人工管理服装的缺点与软件设计的优点,基于java语言及软件设计模式开发出了移动式服装管理系统。本项目的开发旨在解放劳动力,使用电脑软件代替繁琐的服装存储、搜查库存、删除剩余量、价格计算等操作,极大方便了服装网店及门面店,同时有效避免人工在服装存储、销售时的差错,提高整个流程正确率。
    面向对象的软件开发中,对同一个问题每个人都可能给出不同的解决方案,为了使软件的开发更高效,更有质量。我们有必要对一些常见的问题的解决方案制定规范,这样就产生了设计模式的概念。设计模式使得人们可以更加简单和方便地去复用成功的软件设计和体系结构,从而能够帮助设计者更快更好的完成系统设计。本次软件设计的另一个目标是通过软件设计模式技术设计一个小型程序来加深小组成员对面向对象和设计模式的思想的认识。结合以上目的,故选择用JAVA语言编写一个服装管理系统来完成此次软件设计。
    1.3功能设计
    服装管理系统的设计是采取面向对象的开发模式进行软件的开发的架设,能很好的满足实际使用的需求,完善了对应的软体架设以及程序编码的工作,采用SSM框架、java技术、Ajax技术进行服装业务系统的编码及其开发,实现了本系统的全部功能。
    核心功能如下图所示:
    图1.1系统功能设计图
    服装管理系统主要分为两个功能模块:服装价格计算模块和商品信息管理块。
    服装价格计算模块主要负责对客户购买服装商品需要支付的金钱进行计算,在输入商品名称、商品单价信息以及客户购买数量等信息后,计算购买商品的总价。其中用户可以选择计算总价的方式:分为“正常收费”,即不使用任何优惠方式,按原价计算;“打八折”,即对正常收费下得价格打八折优惠计算。
    商品信息管理模块主要负责将服装的名称、价格等信息进行存储(添加、保存)、删除(更新服装库存数据)和查找(反馈查询结果清单)、修改(服装价格、数量、类型)等。
  2. 总体设计

2.1系统架构图

图2.1系统架构图

视图层的视图是指被用户所看到的并且能够与之进行交互的界面。视图可以向用户展示相关的数据,并接收用户输入的数据,但对用户数据不进行任何实际业务操作处理。

模型层通过控制层来处理视图层传递的数据,同一个模型可以给不同的视图提供数据,也可以被不同的视图重复使用。由于 Model 的主要内容是数据、方法和行为,其也是逻辑最为复杂,代码量最多的部分,其中包含了许多应用中需要用到的业务逻辑,因此模型层的开发也变得尤为重要,后期一般不会对模型层进行大规模改动。

控制层主要负责视图层和模型层之间的数据传输和处理请求操作。当用户通过视图发送数据和请求时,控制层可以接收请求和数据并决定调用哪些模型、通过模型的哪些操作来处理数据和请求,处理完成后,控制层再将数据返回给相应的视图。

要想在上面的系统中使用到设计模式的思想,必须掌握设计模式的几个原则。设计模式使用的根本原因是为了代码复用,增加系统可维护性。为此,设计模式有以下几个原则:

开放封闭原则(OCP) 软件对扩展应该是开放的,对修改应该是封闭的。即开发一个软件时应该对它进行功能扩展,而在进行这些扩展时不需要对原来的程序进行修改。该原则的实现主要依靠抽象,要面向接口,把系统的所有可能的行为抽象成一个抽象底层,这个抽象底层规定出所有的具体类必须提供的方法的特征。以其作为系统设计的抽象层,这个抽象层要预见所有可能的扩展,从而使得在任何扩展的情况下,系统的抽象层不需要修改,同时由于抽象层导出一个或者多个新的具体类可改变系统的行为,因此对于可变的部分,系统的设计是开放的。

单一职责原则(SRP) 一个类应该仅有一个引起它变化的原因。如果多于一个动机去改变一个类,那么这个类就具有多个一个的职责,应该把多余的职责分离出去,分布再创建一些类来完成每一个职责。SRP原则是实现高内聚低耦合的最好办法。如果变化总是引起两个或者多个职责同时发生变化,最好应该将这些职责放到同一个类中去。

里氏代换原则(LSP) 继承必须确保超类所拥有的性质在子类中任然成立,即当一个子类的实例能够替换任何其超类的实例时,他们之间才具有继承关系。

依赖倒置原则(DIP) 如果一个类的一个成员或者参数为一个具体的类型,那么这个类就依赖于那个具体类型。如果一个继承结构中,上层类中的一个成员或者参数为一个下层的类型,那么这个继承结果就是高依赖于底层。系统的类机构应该尽量由高层依赖于底层变成高层底层同时依赖于抽象。高层模块只应该包含重要的业务模型和策略选择,底层模块是不同业务和策略的实现。高层抽象不依赖于高层和底层的具体实现,最多只依赖于底层的抽象。高层的实现独立于底层模块,不应该依赖于低层模块,而是依赖于低层抽象。

2.2接口设计

在CashSuper包下,创建CashSuper接口。

public interface CashSuper {
public abstract double acceptCash(double money);
}

CashSuper接口在CashNormal包以及CashRebate包中被调用,完成服装价格及折扣计算方法的声明。

public class CashNormal implements CashSuper{
@Override
public double acceptCash(double money){
return money;
}

}

public class CashRebate implements CashSuper{
private double rate = 1d;
@Override
public double acceptCash(double money){
return money * rate;
}
public CashRebate (String rate)
{
this.rate = Double.parseDouble(rate);
}
}

之后在Goods包下,add()、delete()、modify()方法实现服装的添加、删除和修改功能。最后在ui包下的主程序中实现接口。

图2.2接口调用

  1. 详细设计

3.1服装价格计算模块设计

服装价格模块的程序流程图如下图所示:

 

输入商品名称

 

输入商品单价

 

输入商品数量

 

计算方式选择

 

正常模式

打八折

 

输出应付金额

图3.1价格模块流程图

该模块所使用的设计模式有:简单工厂模式、单例模式、策略模式和装饰模式。模块实现界面截图如下:

图3.2计算模块图

下面分别对这四种设计模式进行简单介绍:

3.1.1工厂模式

简单工厂模式又称静态工厂方法模式,它定义一个具体的工厂类来负责创建一些类的实例,而这些被创建的类都应该有一个共同的父类,这样就可以实现面向抽象而不是面向具体编程。简单工厂模式主要由三部分组成:工厂类、抽象类和实现抽象类的具体类。简单工厂模式的原理图如图所示:

图3.3简单工厂模式类图

简单工厂模式的示意代码:

抽象产品类

public interface Product {

void operation1 ( );

}

具体产品类:

public class Product1 implements Product {

public void operation1 ( ) {

}

}

public class Product2 implements Product {

public void operatiom2 ( ) {

}

}

工厂类:

public class SampleFactory {

public static Product createProduct ( String productName ) {

if ( “1” .equals ( productName ) )

return new Product1 ( );

else if (“2”.equals ( productName ) )

return new Product2 ( );

return null;

}

}

当代码中使用new来创建对象时,就可以考虑使用简单工厂模式了。一般用于比较简单的对象创建上。

简单工厂类在商品价格计算模块的实际应用如下:

public class CashFactory {
public static CashSuper createCashAccept(String type)
{
CashSuper cs = null;
if(type.equals("正常收费"))
{
CashNormal cr0 = new CashNormal();
cs = cr0;
}
else if(type.equals("打八折"))
{
CashRebate cr1= new CashRebate("0.8");
cs = cr1;
}
return cs;
}
}

在这里,我们设计了CashFactory这个类,对于用户的选择,设计了两种收费方式,对应的新建了两种类,有CashNormal(); (正常收费模式)CashRebate("0.8");(打八折收费模式)。这2个种收费方式分别在这3个类中实现。

3.1.2单例模式

单例模式就是确保一个类只有一个实例,并且该实例必须自动创建,并向整个系统提供该实例。单例模式可以分为饿汉式单例模式和懒汉式单例模式。饿汉式单例模式在类的初始化时就创建了自身的对象而懒汉式单例模式是在需要时才创建自身的对象。单例模式的原理图如下:

图3.4单例模式类图

单例模式代码如下:

public class CashContext {

private static CashContext singleInstance = new CashContext(); //单例模式
private CashContext()
{

}
public CashContext getInstance(){
return singleInstance;
}
public CashContext(CashSuper cs) {
this.cs = cs;
}

public double GetResult(double money)
{
return cs.acceptCash(money);
}
private CashSuper cs;
}

在这里,其实单例模式主要是起了学习编程的作用,并且想到该程序在日后开发中可能涉及到多用户的同时操作,在面对多线程或者多用户操作的时候起到一定提醒作用。

3.1.3策略模式

策略模式就是定义了一系列的算法,并将每一个算法封装起来,而且使它们还可以互相替换。策略模式让算法独立于使用它的客户而独立变化。策略模式主要由三部分组成:抽象策略类、具体策略类、上下文场景类。策略模式的原理图如下图所示:

 

Context

+operation:void

Interface

Strategy

+operation:void

 

 

Strategy1

+operation:void

Strategy2

+operation:void

 

图3.5策略模式的原理图

图3.6策略模式类图

抽象策略类的示意代码

public interface Strategy {

void operation1 ( );

}

策略类1的示意代码

public class Strategy1 implements Strategy {

public void operation1 ( ) {

}

}

策略类2的示意代码

public class Strategy2 implements Strategy {

public void operation1 ( ) {

}

}

上下文类的示意代码

public class Context {

public void operation1 ( ) {

lnkStrategy.operation1 ( ) ;

}

Private Strategy lnkStrategy;

}

当系统需要能够在几种算法中迅速的切换,或者系统中有一些类他们仅行为不同时,或系统中存在多重条件选择语句时,就可以考虑使用策略模式。

策略模式在系统中的具体应用在CashSuper类与CashContext中,由于是与工厂模式结合的,就不再详细说明。

代码如下:

public interface CashSuper {
public abstract double acceptCash(double money);
}

3.1.4装饰模式

装饰模式是使用被装饰类的一个子类的实例,在客户端将这个子类的实例委托给装饰类。装饰模式是继承关系的一个替代方案。装饰模式主要有四部分组成:抽象的被装饰类、具体的被装饰类、抽象的装饰类、具体的被装饰类。装饰模式的原理图如图所示:

 

Interface

Component

+sampleOperation:void

 

 

Decorator

-component:Conponent

+Decorator

+sampleOperation:void

 

 

ConcreteComponent

+sampleOperation:void

 

 

ConcreteDecorator

+sampleOperation:void

 

图3.7装饰模式的原理图

图3.8装饰模式类图

抽象的被装饰类的示意代码

public interface Component {

void sampleOperation ( );

}

具体的被装饰类的示意代码

public class ConcreteComponent implements Component {

public void sampleOperation ( ) {

}

}

抽象的装饰类的示意代码

public class Decorator implements Component {

public Decorator ( Component component) {

super ( );

this.component = component;

}

public void sampleOperation ( ) {

component.sampleOperation( );

}

Private Conponent component;

}

具体的装饰类的示意代码:

public class ConcreteDecorator extends Decorator {

public void sampleOperation ( ) {

super.sampleOperation ( );

}

当系统需要扩展一个类的功能或者客户端需要动态的给一个对象添加功能,并且此时如果使用继承会很复杂时,就会使用装饰模式。

装饰模式在系统中的实际应用如下:

首先设计了输出类 OutputChoice,其中有个String out,其后对于每一个输入的信息,我们可以通过相应的类将信息进行整合。原理上相当于简单的String a1+String a2 的方式,但是,通过装饰模式,我们还可以对于每一个信息进行相应的处理,如在OutputNum中,我们要求用户输入的购买数据时数字,如果不是数字则予以提示,并不用进行接下来的”装饰”。

public class OutputNum extends Finery{
public OutputNum(String num){
out = num;
}
@Override
public String Set(String str)
{
try{
num = Integer.parseInt(out);
out = "\t数量:" + out +str;
return super.Set(out);
}catch(Exception e){
num = 0;
return "错误\n购买数量输入不合法\n";
}
}
public int getNum(){
return num;
}
private int num;
private String out;
}

3.2服装信息管理模块的设计

服装信息管理模块的设计流程图如下所示:

 

服装信息

管理模块

 

修改

 

添加

删除

查询

 

输入商品名称

输入商品名称和修改后的价格

输入商品名称和价格

输入商品名称

 

保存

保存

查询结果清单

保存

图3.9信息管理模块的设计流程图

该模块所使用的设计模式有模板模式。模块实现界面截图如下:

图3.10模块实现界面图

3.2.1模板模式

模板方法模式就是定义一个算法执行的骨架,而将具体算法延迟到子类中去实现。模板方法模式主要由两部分组成:抽象的骨架类、具体的实现类。模板方法模式的原理图如下图所示:

 

Template

+operation1:void

+operation2:void

+operation3:void

+TemplateMethod:void

 

 

Templatelm pl

+operation1:void

+operation2:void

+operation3:void

图3.11模板方法模式的原理图

图3.12模板方法模式类图

抽象的骨架类示意代码

public abstract class Template {

public abstract void operation1 ( );

public abstract void operation2 ( );

public abstract void operation3 ( );

public void TemplateMethod ( ) {

operation1 ( );

operation2 ( );

operation3 ( );

}

}

具体实现类的示意代码

public class TemplateImpl extends Template {

public void operation1 ( ) {

}

public void operation2 ( ) {

}

public void operation3 ( ) {

}

当系统中算法的骨架是固定的,而算法的实现可能有很多种的时候,就需要使用模板方法模式。

模板方法模式在系统中的具体应用如下:

在GoodsList中设计初始算法如下:

public abstract boolean add(Goods goods);
public abstract boolean delete(String name);
public abstract boolean modify(String name,Goods goods);

然后在GoodsMethod类中实现具体的初步算法:

@Override
public boolean add(Goods goods){
int flag = super.Search(goods.getName());
if(flag < 0){
goodslist.add(goods);
return true;
}else{
return false;
}
}
@Override
public boolean delete(String name){
int flag = super.Search(name);
if(flag < 0)
return false;
else{
goodslist.remove(flag);
return true;
}
}
@Override
public boolean modify(String name,Goods goods){
int flag = super.Search(name);
if(flag < 0)
return false;
flag = super.Search(goods.getName());
if(flag < 0)
return false;
else{
goodslist.get(flag).setName(goods.getName());
goodslist.get(flag).setPrice(goods.getPrice());
return true;
}
}

3.3系统总体类图

服装管理系统代码分类如上图所示,主要分为decorator包、Factory_Strategy包、Goods包和Ui包。各包总体类图如下所示:

图3.13decorator包类图

图3.14Factory_Strategy包类图

图3.15Goods包类图

图3.16服装管理系统总体类图

  • 24
    点赞
  • 20
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值