精华内容
下载资源
问答
  • uml 文档 命令模式

    2011-06-22 22:16:17
    先从起源说起。在设计界面时,大家可以注意到这样的一种情况,同样的菜单控件,在不同的应用环境中的功能是完全不同的;而菜单选项的某个功能可能和鼠标右键的某个功能完全一致。
  • 设计模式--命令模式--UML

    千次阅读 2013-11-26 14:59:41
    命令模式:

    命令模式:

    展开全文
  • 设计模型之命令模式 1. 命令模式 1.1 定义与特点   命令(Command)模式的定义如下:将一个请求封装为一个对象,使发出请求的责任和执行请求的责任分割开。这样两者之间通过命令对象进行沟通,这样方便将命令对象...

    设计模型之命令模式

    1. 命令模式

    1.1 定义与特点

      命令(Command)模式的定义如下:将一个请求封装为一个对象,使发出请求的责任和执行请求的责任分割开。这样两者之间通过命令对象进行沟通,这样方便将命令对象进行储存、传递、调用、增加与管理。

      命令模式的主要优点如下:

    • 降低系统的耦合度。
    • 命令模式能将调用操作的对象与实现该操作的对象解耦。
    • 增加或删除命令非常方便。
    • 采用命令模式增加与删除命令不会影响其他类,它满足“开闭原则”,对扩展比较灵活。
    • 可以实现宏命令。
    • 命令模式可以与组合模式结合,将多个命令装配成一个组合命令,即宏命令。
    • 方便实现 Undo 和 Redo 操作。
    • 命令模式可以与后面介绍的备忘录模式结合,实现命令的撤销与恢复。

      命令模式的缺点是:

    • 可能产生大量具体命令类。
    • 因为计对每一个具体操作都需要设计一个具体命令类,这将增加系统的复杂性。

    1.2 模式的结构

      命令模式包含以下主要角色:

    • 抽象命令类(Command)角色:声明执行命令的接口,拥有执行命令的抽象方法 execute()。
    • 具体命令角色(Concrete
      Command)角色:是抽象命令类的具体实现类,它拥有接收者对象,并通过调用接收者的功能来完成命令要执行的操作。
    • 实现者/接收者(Receiver)角色:执行命令功能的相关操作,是具体命令对象业务的真正实现者。
    • 调用者/请求者(Invoker)角色:是请求的发送者,它通常拥有很多的命令对象,并通过访问命令对象来执行相关请求,它不直接访问接收者。

    1.3 问题由来

    在软件开发系统中,常常出现“方法的请求者”与“方法的实现者”之间存在紧密的耦合关系。这不利于软件功能的扩展与维护。例如,想对行为进行“撤销、重做、记录”等处理都很不方便,因此“如何将方法的请求者与方法的实现者解耦?”变得很重要,命令模式能很好地解决这个问题。在现实生活中,这样的例子也很多,例如,电视机遥控器(方法的请求者)遥控电视机(命令接收者)
    代码示例如下:

    
    /**
     * @author tbb
     *      家用电器类
     */
    public abstract class HouseholdElectricalAppliances 
    {
        abstract String kind();
        abstract void open();
        abstract void close();
    }
    
    
    /**
     * @author tbb
     *     空调
     */
    public class AirConditioning extends HouseholdElectricalAppliances  {
    
    	@Override
    	public void open() 
    	{
    		System.out.println("打开" + kind());
    	}
    
    	@Override
    	public void close() 
    	{
    		System.out.println("关闭" + kind());		
    	}
    
    	@Override
    	String kind() {
    		return "空调";
    	}
    
    }
    
    /**
     * @author tbb
       *      电视类
     */
    public class Tv  extends HouseholdElectricalAppliances 
    {
    
    	@Override
    	public void open() 
    	{
    		System.out.println("打开" + kind());
    	}
    
    	@Override
    	public void close() 
    	{
    		System.out.println("关闭" + kind());		
    	}
    
    	@Override
    	String kind() {
    		return "电视";
    	}
          
    }
    
    /**
     * @author tbb
     *      控制器
     */
    public class Control 
    {
         public void open(HouseholdElectricalAppliances hea)
         {
        	 hea.open();
         }
         
         public void close(HouseholdElectricalAppliances hea)
         {
        	 hea.close();
         }
         
    	
    }
    
    public class Test 
    {
           public static void main(String[] args) 
           {
    		   Tv tv = new Tv();
    		   Control control = new Control();
    		   AirConditioning airConditioning = new AirConditioning();
    		   control.open(tv);
    		   control.close(tv);
    		   control.open(airConditioning);
    		   control.close(airConditioning);
    		   /*
    		                       打开电视
    				关闭电视
    				打开空调
    				关闭空调
    		    */
    	   }
    }
    

    1.4 解决思路

      解决方法就是采用命令模型,第一步将“方法的请求者”与“方法的实现者”进行解耦,例如将电视机遥控器(方法的请求者)和遥控电视机(方法的实现者)解耦,分为电视机遥控器(命令发送者)通过按钮(具体命令)来遥控电视机(命令接收者)。

    1.5 UML类图

    在这里插入图片描述

    1.6 解决方案

    /**
     * @author tbb
     *     命令
     */
    public interface Command 
    {
        void execute();
    }
    
    
    /**
     * @author tbb
     *      打开命令
     */
    public class OpenCommand implements Command
    {
        private HouseholdElectricalAppliances hev;
        
    	@Override
    	public void execute() 
    	{
    		this.hev.open();
    	}
    
    	public OpenCommand(HouseholdElectricalAppliances hev) {
    		super();
    		this.hev = hev;
    	}
    
    	
    	
    
    }
    
    /**
     * @author tbb
     *      关闭命令
     */
    public class CloseCommand implements Command
    {
        private HouseholdElectricalAppliances hev;
    	@Override
    	public void execute() 
    	{
    		hev.close();
    	}
    	public CloseCommand(HouseholdElectricalAppliances hev) {
    		super();
    		this.hev = hev;
    	}
    
    }
    
    /**
     * @author tbb
     *      控制器
     */
    public abstract class Control 
    {
    	
    	abstract void open();
    	abstract void close();
    	
    }
    
    /**
     * @author tbb
     * 家电类控制器
     */
    public class HouseholdElectricalControl extends Control{
    
    	private Command openCommand;
    	private Command closeCommand;
    	
    	public HouseholdElectricalControl(OpenCommand openCommand,CloseCommand closeCommand) {
    		super();
    		this.openCommand = openCommand;
    		this.closeCommand = closeCommand;
    	}
    
    	@Override
    	void open() 
    	{
    		this.openCommand.execute();
    	}
    
    	@Override
    	void close() 
    	{
    		this.closeCommand.execute();
    	}
    
    }
    
    
    /**
     * @author tbb
     *      家用电器类
     */
    public abstract class HouseholdElectricalAppliances 
    {
        abstract String kind();
        abstract void open();
        abstract void close();
    }
    
    
    /**
     * @author tbb
     *     空调
     */
    public class AirConditioning extends HouseholdElectricalAppliances  {
    
    	@Override
    	public void open() 
    	{
    		System.out.println("打开" + kind());
    	}
    
    	@Override
    	public void close() 
    	{
    		System.out.println("关闭" + kind());		
    	}
    
    	@Override
    	String kind() {
    		return "空调";
    	}
    
    }
    
    
    /**
     * @author tbb
       *      电视类
     */
    public class Tv  extends HouseholdElectricalAppliances 
    {
    
    	@Override
    	public void open() 
    	{
    		System.out.println("打开" + kind());
    	}
    
    	@Override
    	public void close() 
    	{
    		System.out.println("关闭" + kind());		
    	}
    
    	@Override
    	String kind() {
    		return "电视";
    	}
          
    }
    
    
    public class Test 
    {
         public static void main(String[] args) 
         {
        	 Tv tv = new Tv();
        	 OpenCommand openCommand = new OpenCommand(tv);
        	 CloseCommand closeCommand = new CloseCommand(tv);
        	 HouseholdElectricalControl control = new HouseholdElectricalControl(openCommand, closeCommand);
        	 control.open();
        	 control.close();
        	 AirConditioning airConditioning = new AirConditioning();
        	 openCommand = new OpenCommand(airConditioning);
        	 closeCommand = new CloseCommand(airConditioning);
        	 control = new HouseholdElectricalControl(openCommand, closeCommand);
        	 control.open();
        	 control.close();
        	 /*
    	        打开电视
    			关闭电视
    			打开空调
    			关闭空调
        	  */
         }
    }
    
    展开全文
  • 在讨论命令设计模式时,通常会有几个对象,每个对象都有自己的特定角色: 1.命令:我们可以将其视为调用者调用的接口及其实现。{ MakeSandwichCommand,CleanUpCommand PourJuiceCommand} 2.Receiver:这是实际知道...

     

     

    在讨论命令设计模式时,通常会有几个对象,每个对象都有自己的特定角色:

    1.命令:我们可以将其视为调用者调用的接口及其实现。{ MakeSandwichCommand,CleanUpCommand PourJuiceCommand}

    2.Receiver:这是实际知道如何执行命令的对象。可以将此视为传递给命令的对象,然后在接口方法中使用。{Robot}

    3.Invoker:它通过调用它们的接口方法来调用命令。正如我们前面提到的,它甚至可能不知道正在调用哪些命令。{RobotController}

    4.客户端:它或多或少地指导使用调用者执行哪些命令。{RobotExample,RobotByNameExample}

     

    既然我们知道了最重要的对象及其在命令设计模式中的作用,我们可以看一个例子。对于类图,我们假设我们有一个可以烹饪的机器人。

    我们通过控制器连接它并向我们的机器人发送命令。事情很简单,但应该足以理解这种模式是如何工作的。这是类图:我们可以在这里快速识别RobotCommand接口及其实现是命令。接收器是Robot类,因为它知道如何运行发出给它的所有命令。

    RobotController类是调用者。它不知道它执行什么类型的命令,只需在需要时运行它们。

    我们没有在上图中显示我们的客户端类,因为它只是由运行代码的示例应用程序表示,该代码实现了先前显示的类图。

    您可以很容易地看到,如果更改了代表上图的代码,它可以轻松添加多线程支持并支持撤消。

    代码示例现在,是时候看到代表上一个图表的有趣部分 - 代码。与往常一样,我们将通过各个班级,并在必要时作出简要说明。

    我们将要看的第一段代码是Robot类。我们已经提到它充当接收器并且知道如何执行某些特定功能:我们保持代码简单,并且方法只是向命令行打印不同的东西。接下来是具有不同实现的robot命令:

     

    前面的代码绝对没有什么特别之处。它是一个简单的特征,由不同的类实现。它依赖于Robot接收器,它知道如何执行方法。

    RobotController类是我们的调用者,并根据RobotCommand接口发出给它的命令。只要遵循接口,它就不需要知道它发出的命令。我们已经决定添加一些可以在以后用于回滚的命令的历史记录。调用程序的代码如下所示:Scala方式的命令设计模式命令设计模式是设计模式的另一个示例,与其他语言相比,它可以在Scala中以不同方式实现。我们将展示前面示例的另一个实现。这次,我们将使用该语言的by-name参数功能。它可以作为参数传递函数(我们之前已经看过的策略设计模式),但更详细。让我们看看它会是什么样子。

    实际上不太需要改变应用程序。我们只重构并重命名了RobotController和RobotExample类。

    这是前一个类,现在称为RobotByNameController:

    class RobotByNameController {

    val history = ListBuffer [()=> Unit]()def issueCommand(command:=> Unit):Unit = {command _ =:history command} d ef showHistory( ):Unit = {history.foreach(println)}

    }

    正如您所看到的,我们不会将一个实际的命令对象,而只是一个by-name参数传递给issueCommand方法。这个方法的作用是将调用推迟检索传递的值,直到实际需要它为止。为了使前面的代码工作,我们还必须重构我们的示例代码:当我们不想为命令接口及其实现编写额外的代码时,by-name参数方法很有用。我们可以直接传递任何函数调用(在这种情况下,直接来自接收器),它将一直保持到需要数据或根本不调用。输出将与以前相同,但现在我们有功能,历史打印输出看起来会略有不同。

    对于我们想要因某种原因而延迟,记录或排序方法调用的情况,命令设计模式非常有用。

    case class Robot() {

    def cleanUp(): Unit = System.out.println("Cleaning up.")

     

    def pourJuice(): Unit = System.out.println("Pouring juice.")

     

    def makeSandwich(): Unit = System.out.println("Making a sandwich.")

    }

     

     

    import scala.collection.mutable.ListBuffer

     

    trait RobotCommand {

    def execute(): Unit

    }

     

    case class MakeSandwichCommand(robot: Robot) extends RobotCommand {

    override def execute(): Unit = robot.makeSandwich()

    }

     

    case class PourJuiceCommand(robot: Robot) extends RobotCommand {

    override def execute(): Unit = robot.pourJuice()

    }

     

    case class CleanUpCommand(robot: Robot) extends RobotCommand {

    override def execute(): Unit = robot.cleanUp()

    }

     

    class RobotController {

    val history = ListBuffer[RobotCommand]()

    def issueCommand(command: RobotCommand): Unit = {

    command +=: history

    command.execute()

    }

    def showHistory(): Unit = {

    history.foreach(println)

    }

    }

     

    class RobotByNameController {

    val history = ListBuffer[() => Unit]()

     

    def issueCommand(command: => Unit): Unit = {

    command _ +=: history

    command

    }

     

    def showHistory(): Unit = {

    history.foreach(println)

    }

    }

     

    object RobotExample {

    def main(args: Array[String]): Unit = {

    val robot = Robot()

    val robotController = new RobotController

    robotController.issueCommand(MakeSandwichCommand(robot))

    robotController.issueCommand(PourJuiceCommand(robot))

    System.out.println("I'm eating and having some juice.")

    robotController.issueCommand(CleanUpCommand(robot))

    System.out.println("Here is what I asked my robot to do:")

    robotController.showHistory()

    }

    }

     

    object RobotByNameExample {

    def main(args: Array[String]): Unit = {

    val robot = Robot()

    val robotController = new RobotByNameController

     

    robotController.issueCommand(MakeSandwichCommand(robot).execute())

    robotController.issueCommand(PourJuiceCommand(robot).execute())

    System.out.println("I'm eating and having some juice.")

    robotController.issueCommand(CleanUpCommand(robot).execute())

     

    System.out.println("Here is what I asked my robot to do:")

    robotController.showHistory()

    }

    }

     

    执行结果:

     

    展开全文
  • UML类图

    千次阅读 2018-05-12 11:16:37
    UML类图》#第一篇:UML基础++第一篇:UML基础++UML简述++++UML(Unified Modeling Language)又称统一建模语言或标准建模语言,是始于1997年一个OMG标准,它是一个支持模型化和软件系统开发的图形化语言,为软件...

    UML类图》

    #第一篇:UML基础

    ++第一篇:UML基础



    ++UML简述

    ++++UMLUnified Modeling Language)又称统一建模语言或标准建模语言,是始于1997年一个OMG标准,它是一个支持模型化和软件系统开发的图形化语言,为软件开发的所有阶段提供模型化和可视化支持,包括由需求分析到规格,到构造和配置。

    ++++UML规范用来描述建模的概念有:类(对象的)、对象、关联、职责、行为、接口、用例、包、顺序、协作,以及状态。

    ++UML主要内容

    ++++统一建模语言(UMLUnified Modeling Language)是面向对象软件的标准化建模语言。

    ++++UML因其简单、统一的特点,而且能表达软件设计中的动态和静态信息,目前已成为可视化建模语言的工业标准。

    ++++UML3个要素构成:UML的基本构造快、支持这些构造块如何放置在一起的规则和运用于整个语言的公用机制。

    ++++UML3种基本的构造块:事物、关系和图。

    ++++事物是对模型中最具有代表性的成分的抽象,包括:结构事物、行为事物、分组事物和注释事物。

    --结构事物,如类(Class)、接口(Interface)、协作(Collaboration)、用例(UseCase)、主动类(ActiveClass)、组件(Component)和节点(Node);

    --行为事物,如交互(Interaction)、状态机(Statemachine);

    --分组事物,包(Package);

    --注释事物,注释(Note)。

    ++++关系用来把事物结合在一起,包括依赖、关联、泛化和实现关系。

    ++UML定义的9种图

    ++++UML从考虑系统的不同角度出发,定义了用例图、类图、对象图、状态图、活动图、序列图、协作图、构件图、部署图等9种图。

    ++++这些图从不同的侧面对系统进行描述。

    ++++系统模型将这些不同的侧面综合成一致的整体,便于系统的分析和构造。

    ++UML特点

    ++++UML统一了各种方法对不同类型的系统、不同开发阶段以及不同内部概念的不同观点,从而有效的消除了各种建模语言之间不必要的差异。它实际上是一种通用的建模语言,可以为许多面向对象建模方法的用户广泛使用。

    ++++UML建模能力比其它面向对象建模方法更强。它不仅适合于一般系统的开发,而且对并行、分布式系统的建模尤为适宜。

    ++++UML是一种建模语言,而不是一个开发过程。

    ++UML应用

    ++++UML已成功应用于电信、金融、政府、电子、国防、航天航空、制造与工业自动化、医疗、交通、电子商务等领域中。

    ++++在这些领域中,UML的建模包括大型、复杂、实时、分布式、集中式数据或者计算,以及嵌入式系统等,而且还用于软件再生工程、质量管理、过程管理、配置管理的各方面。



    #第二篇:UML在设计模式中的应用

    #第二篇:UML在设计模式中的应用



    ++2.1、单例模式

    ++++单例模式(Singleton):保证一个类仅有一个实例,并提供一个访问它的全局访问点。



    ++2.2、工厂方法模式

    ++++工厂方法模式(Factory Method):定义一个用于创建对象的接口,让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。




    ++2.3、抽象工厂模式

    ++++抽象工厂模式(Abstract Factory):提供一个创建一系列相关或相互依赖对象的接口,而无需指定它们具体的类。




    ++2.4、建造者模式

    ++++建造者模式(Builder):将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示。




    ++2.5、原型模式

    ++++原型模式(Prototype):用原型实例指定创建对象的种类,并且通过拷贝这些原型创建新的对象。




    ++2.6、适配器模式

    ++++适配器模式(Adapter):将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。




    ++2.7、装饰模式

    ++++装饰模式(Decorator):动态地给一个对象添加一些额外的职责,就增加功能来说,装饰模式比生成子类更为灵活。



    ++2.8、桥接模式

    ++++桥接模式(Bridge):将抽象部分与它的实现部分分离,使它们都可以独立地改变。




    ++2.9、组合模式

    ++++组合模式(Composite):将对象组合成树形结构以表示“部分-整体”的层次结构。组合模式使得用户对单个对象和组合对象的使用具有一致性。



    ++2.10、享元模式

    ++++享元模式(Flyweight):运用共享技术有效地支持大量细粒度的对象。



    ++2.11、代理模式

    ++++代理模式(Proxy):为其他对象提供一种代理以控制对这个对象的访问。



    ++2.12、外观模式

    ++++外观模式(Facade):为子系统中的一组接口提供一个一致的界面,此模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。



    ++2.13、观察者模式

    ++++观察者模式(Observer):定义了一种一对多的依赖关系,让多个观察者对象同时监听某一个主题对象。这个主题对象在状态发生变化时,会通知所有观察者对象,使它们能够自动更新自己。



    ++2.14、模板方法

    ++++模板方法(Template Method):定义一个操作中的算法的骨架,而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。




    ++2.15、命令模式

    ++++命令模式(Command):将一个请求封装为一个对象,从而使我们可用不同的请求对客户进行参数化;对请求排队或记录请求日志,以及支持可撤销的操作。




    ++2.16、状态模式

    ++++状态模式(State):当一个对象的内在状态改变时允许改变其行为,这个对象看起来像是改变了其类。



    ++2.17、职责链模式

    ++++职责链模式(Chain of Responsibility):使多个对象都有机会处理请求,从而避免请求的发送者和接收者之间的耦合关系。将这个对象连成一条链,并沿着这条链传递该请求,直到有一个对象处理它为止。




    ++2.18、解释器模式

    ++++解释器模式(interpreter):给定一个语言,定义它的文法的一种表示,并定义一个解释器,这个解释器使用该表示来解释语言中的句子。



    ++2.19、中介者模式

    ++++中介者模式(Mediator):用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用,从而使其耦合松散,而且可以独立地改变它们之间的交互。



    ++2.20、访问者模式

    ++++访问者模式(Visitor):表示一个作用于某对象结构中的各元素的操作。它使我们可以在不改变各元素的类的前提下定义作用于这些元素的新操作。




    ++2.21、策略模式

    ++++策略模式(Strategy):它定义了算法家族,分别封装起来,让它们之间可以相互替换,此模式让算法的变化,不会影响到使用算法的客户。




    ++2.22、备忘录模式

    ++++备忘录模式(Memento):在不破坏封装性的前提下,捕获一个对象的内部状态,并在该对象之外保存这个状态。这样以后就可将该对象恢复到原先保存的状态。




    ++2.23、迭代器模式

    ++++迭代器模式(Iterator):提供一种方法顺序访问一个聚合对象中各个元素,而又不暴露该对象的内部表示。





    #第三篇:UML拓展

    #第三篇:UML拓展

    +++++此部分是立钻哥哥从不同角度和领域分析拓展UML类图。

    ++++3.1、详解UML图之类图

    ++++3.2UML类图中类与类之间的关系

    ++++3.3、类图以及类与类之间的关系

    ++++3.4UML类图设计

    ++++3.5、读懂UML类图

    ++++3.6UML类图简单介绍

    ++++3.7、深入浅出UML类图

    ++++3.8UML类图详解


    ##3.1、详解UML图之类图

    ++3.1、详解UML图之类图

    ++++产品经理的必备技能之一是画UML图。

    ++++使用工具:Visio或者Processon在线作图。

    ++类图中模型元素

    ++++在类图中一共包含的模型元素:类(Class)、接口(Interface)以及类之间的关系。

    ++++类(Class):

    --在面向对象(OO)编程中,类是对现实世界中一组具有相同特征的物体的抽象。

    ++++接口(Interface):

    --接口是一种特殊的类,具有类的结构但不可被实例化,只可以被实现(继承)。在UML中,接口使用一个带有名称的小圆圈来表示。

    ++++类图中关系(relation):

        --UML类图中,常见的关系:泛化(Generalization),实现(Realization),关联(Association),聚合(Aggregation),组合(Composition),依赖(Dependency)。

    ++类图中关系(relation

    ++++1、泛化(Generalization)关系:是一种继承关系,表示一般与特殊的关系,它指定了子类如何特化父类的所有特征和行为。(箭头指向:带三角箭头的实线,箭头指向父类。)

    ++++2、实现(Realization)关系:是一种类与接口的关系,表示类是接口所有特征和行为的实现。(箭头指向:带三角箭头的虚线,箭头指向接口。)

    ++++3、关联(Association)关系:是一种拥有的关系,它使一个类知道另一个类的属性和方法。双向的关联可以有两个箭头或者没有箭头,单向的关联有一个箭头。(代码体现:成员变量。)(箭头及指向:带普通箭头的实心线,指向被拥有者。)

    ++++4、聚合(Aggregation)关系:整体与部分的关系,且部分可以离开整体而单独存在。聚合关系是关联关系的一种,是强的关联关系;关联和聚合在语法上无法区分,必须考察具体的逻辑关系。(例如:车和轮胎是整体和部分的关系,轮胎离开车仍然可以存在。)(代码体现:成员变量。)(箭头及指向:带空心菱形的实心线,菱形指向整体。)

    ++++5、组合(Composition)关系:是整体与部分的关系,但部分不能离开整体而单独存在。组合关系是关联关系的一种,是比聚合关系还要强的关系,它要求普通的聚合关系中代表整体的对象负责代表部分的对象的生命周期。(比如:嘴巴属于头部,嘴巴离开头,不能独立存在。)(代码体现:成员变量。)(箭头及指向:带实心菱形的实线,菱形指向整体。)

    ++++6、依赖(Dependency)关系:是一种使用的关系,即一个类的实现需要另一个类的协助,所以要尽量不使用双向的相互依赖。(代码表现:局部变量、方法的参数或者对静态方法的调用。)(箭头及指向:带箭头的虚线,指向被使用者。)

    ++++各种关系的强弱顺序:泛化=实现>组合>聚合>关联>依赖。


    ++UML实践总结:

    ++++软件分析与设计是编码前的两个阶段,其中分析仅与业务有关,而与技术无关。设计以分析为基础,主要与具体技术有关。

    ++++分析阶段由分析师绘制领域UML类图,设计阶段由设计师绘制实现UML类图。

    ++++领域UML类图表示系统的静态领域结构,其中的类不与最终程序中的类对应;设计UML类图表示系统的技术架构,是程序员的编码依据,其中的类与系统中的类对应。

    ++++领域UML类图中类的属性与操作仅关注与业务有关的部分,实现UML类图中的属性与操作要包括最终需要实现的全部方法和操作。



    ##3.2UML类图中类与类之间的关系

    ++3.2UML类图中类与类之间的关系

    ++++UML类图中的关系:依赖关系(Dependency)、关联关系(Association)、聚合关系(Aggregation)、组合关系(Composition)、继承关系(Inheritance)。



    ++3.2.1、依赖关系(Dependency

    ++++单向,表示一个类依赖于另一个类的定义,其中一个类的变化将影响另外一个类,是一种“use a”关系。(如果A依赖于B,则B表现为A的局部变量,方法参数,静态方法调用等。)

    ++++代码参考(Zuanzuan依赖于Love,则Love表现为Zuanzuan的局部变量,方法参数,静态方法调用等。):

    public class Zuanzuan{

        string name = Love:getName();    //静态方法调用

     

        public void Lovezuanzuan(){

            Love mylove = new Love();    //局部变量

        }

     

        //方法参数

        public void ToLoveMe(Love myLove){

        }

    }


    ++3.2.2、关联关系(Association

    ++++单向或双向(通常我们需要避免使用双向关联关系),是一种“has a”关系,如果A单向关联B,则可以说“A has a B”,通常表现为全局变量。

    ++3.2.3、聚合关系(Aggregation

    ++++单向,关联关系的一种,与关联关系之间的区别是语义上的,关联的两个对象通常是平等的,聚合则一般不平等,有一种整体和局部的感觉,实现上区别不大。

    ++3.2.4、组合关系(Composition

    ++++单向,是一种强依赖的特殊聚合关系。

    ++++如果整体不存在了,部分也将消亡。

    ++++代码示例(HeadBodyArmLeg组合成People,其生命周期相同):

    public class Person{

        public Head head;

        public Body body;

        public Arm arm;

        public Leg leg;

     

        public Person(){

            head = new Head();

            body = new Body();

            arm = new Arm();

            leg = new Leg();

        }

    }


    ++3.2.5、继承关系(Inheritance

    ++++类实现接口,类继承抽象类,类继承父类都属于这种关系。可分为:实现和泛化。

    ++++实现(Realization):类实现接口属于这种关系。

    ++++泛化(Generalization):即“is a”关系,类继承抽象类,类继承父类都属于这种关系。



    ##3.3、类图以及类与类之间的关系

    ++3.3、类图以及类与类之间的关系

    ++++设计模式在程序设计上有着很重要的作用,使用设计模式可以使得代码更容易被理解,使得代码,真正实现工程化。

    ++++类与类之间主要有6种关系:依赖,关联,聚合,组合,继承,实现。

    ++3.3.0、用UML表示一个类

    ++++类图一般是三行的结构:

    --第一行:类名称

    --第二行:属性:格式(可见性 名称:类型[=缺省值]

    --第三行:方法:格式(可见性 名称(参数列表)[返回值类型]

    ++3.3.1、依赖(Dependency

    ++++依赖主要体现了一种使用关系,两个相对独立的对象,当一个对象负责构造另一个对象的实例,或者依赖另一个对象的服务时,主要体现为依赖关系。

    ++++依赖关系主要有3种表现形式(以类A中使用了类B为例):

    --第一种:类B是作为类A的方法参数。

    --第二种:类B是类A的方法中的局部变量。

    --第三种:在类A中调用类B的静态方法。

    ++++在依赖中使用的是“虚线+箭头”。

    ++3.3.2、关联(Association

    ++++关联主要体现的是一种对应关系,两个相对独立的对象,当一个对象的实例与另一个对象的实例存在固定的对应关系时,这两个对象之间为关联关系。通常是将一个类的对象作为另一个类的成员变量。

    ++++关联关系的分类:单向关联、双向关联。

    ++3.3.3、聚合(Aggregation

    ++++聚合是关联关系的一种,表现了一种弱的“拥有”关系,关联关系的对象之间是相互独立的,但是聚合关系的对象之间存在着一种包容关系,体现的是A对象可以包容B对象,但是B对象不是A对象的一部分。它们之间是“整体-个体”的关系。

    ++++成员对象通常作为构造方法、Setter方法或业务方法的参数注入到整体对象中。

    ++++代码举例:

    public class People{

        private Student student;

        private Worker worker;

        private Farmer farmer;

     

        public People(Student student, Worker worker, Farmer farmer){

            this.student = student;

            this.worker = worker;

            this.farmer = farmer;

        }

    }


    ++3.3.4、组合(Composition

    ++++组合是一种强的“拥有”关系,组合中的类之间是“整体-部分”的关系,“整体”负责“部分”的生命周期,“部分”和“整体”的生命周期是一样的,“部分”单独存在是没有任何意义的。通常在整体类的构造方法中直接实例化成员类。

    ++++代码示例(鸟Bird,翅膀Wing):

    public class Bird{

        private Wing wing;

     

        public Bird(){

            wing = new Wing();

        }

    }


    ++3.3.5、继承(Inheritance

    ++++继承表示的是类与类之间或者接口与接口之间的父子关系。

    ++3.3.6、实现(Implementation

    ++++实现表示的是一个类实现一个或多个接口。



    ##3.4UML类图设计

    ++3.4UML类图设计



    ++3.4.1、类

    ++++“动物”矩形框,它代表一个类。

    ++++该类图分为三层:

    --第一层:显示类的名称,如果是抽象类就要用斜体显示。

    --第二层:类的特性,通常就是字段和属性。

    --第三层:类的操作,通常是方法和行为。

    +++++”表示public

    ++++-”表示private

    ++++#”表示protected

    ++3.4.2、接口

    ++++“飞翔”矩形框表示一个接口图,它与类图的区别主要是顶端有《interface》显示。

    ++++第一行是接口名称,第二行是接口方法。

    ++++接口还有另一种表示方法,俗称棒棒糖表示法,就是唐老鸭类实现了“讲人话”的接口。

    ++3.4.3、继承关系

    ++++动物,鸟,鸭,唐老鸭它们之间都是继承的关系,继承关系用空心三角形+实现来表示。

    ++3.4.4、实现接口

    ++++“大雁”实现了“飞翔”接口。

    ++++实现接口用:空心三角形+虚线来表示。

    ++3.4.5、关联关系

    ++++企鹅与气候有很大的关系,企鹅需要“知道”气候的变化,需要“了解”气候规律。

    ++++当一个类“知道”另一个类时,可以用关联(association)关系。

    ++++关联关系用实线箭头来表示。

    ++++代码示例:

    class Penguin : Bird{

        //在企鹅Penguin中,引用到气候Climate对象

        private Climate climate;    

    }

    ++3.4.6、聚合关系

    ++++“大雁”和“雁群”这两个类。

    ++++大雁是群居动物,每只大雁都属于一个雁群,一个雁群可以有多只大雁。所以它们之间就满足聚合(Aggregation)关系。

    ++++聚合表示一种弱的“拥有”关系,体现的是A对象可以包含B对象,但B对象不是A对象的一部分。

    ++++聚合关系用:空心的菱形 + 实线箭头表示。

    ++++代码示例:

    class WideGooseAggregate{

        //在雁群WideGooseAggregate类中,有大雁数组对象arrayWideGoose

        private WideGoose[] arrayWideGoose;

    }

    ++3.4.7、组合关系

    ++++“鸟”和“翅膀”这两个类。

    ++++鸟和翅膀是整体和部分的关系,并且翅膀和鸟的生命周期是相同的,在这里鸟和其翅膀就是组合关系。组合(composition)是一种强的“拥有”关系,体现了严格的部分和整体的关系,部分和整体的生命周期一样。

    ++++组合关系用:实心的菱形+实线箭头来表示。

    ++++组合关系的连线两端还有一个数字“1”和数字“2”,这被称为基数。表明这一端的类可以有几个实例,很显然,一只鸟应该有两只翅膀。(如果一个类可能有无数个实例,则就用“n”来表示。)

    ++++说明:关联关系和聚合关系也可以有基数的。

    ++++代码示例:

    class Bird{

        private Wing wing;

     

        public Bird(){

            //在鸟Bird类中,初始化时,实例化翅膀Wing,它们之间同时生成

            wing = new Wing();

        }

    }


    ++3.4.8、依赖关系

    ++++“动物”、“氧气”和“水”之间。

    ++++动物有几大特征,比如有新陈代谢,能繁殖。

    ++++而动物要有生命,需要氧气,水以及食物等。

    ++++也就是说动物依赖于氧气和水。

    ++++它们之间是依赖关系(Dependency),用虚线箭头来表示。

    ++++代码示例:

    abstract class Animal{

        public Metabolism(Oxygen oxygen, Water water){

        }

    }



    ##3.5、读懂UML类图

    ++3.5、读懂UML类图

    ++++设计应用架构时经常会使用UML类图。

    ++++UML类图中,类使用包含类名、属性(field)和方法(method)且带有分割线的矩形来表示。

    ++++属性的完整表示方式: 可见性  名称 :类型[ = 缺省值]

    ++++方法的完整表示方式: 可见性  名称(参数列表)[: 返回类型]

    +++++】:表示public

    ++++-】:表示private

    ++++#】:表示protected

    ++++类与类之间的表示方式:关联关系、聚合关系、组合关系、依赖关系、继承关系、接口实现关系。

    ++3.5.1、关联关系

    ++++关联关系又可进一步分为单向关联、双向关联和自关联。

    ++++单向关联:在UML类图中单向关联用一个带箭头的直线表示。

    ++++双向关联:就是双方各自持有对方类型的成员变量。在UML类图中,双向关联用一个不带箭头的直线表示。

    +++自关联:在UML类图中用一个带有箭头且指向自身的直线表示。

    ++3.5.2、聚合关系

    ++++UML中聚合关系用带空心菱形和箭头的直线表示。

    ++++聚合关系强调是“整体”包含“部分”,但是“部分”可以脱离“整体”而单独存在。

    ++3.5.3、组合关系

    ++++组合关系与聚合关系最大不同在于:这里的“部分”脱离了“整体”便不复存在。

    ++++UML类图中,组合关系用一个带实心菱形和箭头的直线表示。

    ++3.5.4、依赖关系

    ++++UML类图中,依赖关系用一条带有箭头的虚线表示。

    ++3.5.5、继承关系

    ++++UML类图中用带空心三角形的直线表示。

    ++3.5.6、接口实现关系

    ++++UML类图中用带空心三角形的虚线表示。



    ##3.6UML类图简单介绍

    ++3.6UML类图简单介绍

    ++++UMLUnified Modeling Language:统一建模语言),是非专利的第三代建模和规约语言。

    ++++UML是一种开放的方法,用于说明、可视化、构建和编写一个正在开发的、面向对象的、软件密集系统的制品的开放方法。

    ++3.6.1class UML类图


    ++++空心箭头实线:表示类A继承于类B

    ++++空心箭头虚线:表示小汽车和自行车实现了“车”这个接口。

    ++++带方向的实线:表示A中具有B这个成员变量。

    ++++带方向的虚线:表示A中的一般方法需要B作为传入参数。

    ++++空心菱形实线:表示B中的构造方法(或set方法)需要A作为传入参数。

    ++++实心菱形实线:表示B中构造函数中将A进行了实例化。



    ##3.7、深入浅出UML类图

    ++3.7、深入浅出UML类图

    ++++UML(统一建模语言)是当前软件开发中使用最为广泛的建模技术之一,通过使用UML可以构造软件系统的需求模型(用例模型)、静态模型、动态模型和架构模型。

    ++++UML通过图形和文字符号来描述一个系统,它是绘制软件蓝图的标准语言。

    ++++熟练掌握UML建模技术是一个优秀的软件从业人员所必备的基本技能之一。

    ++3.7.1、用例建模

    ++++UML中,需求模型又称为用例模型,它主要用于描述系统的功能性需求,即软件可以实现的需求。

    ++++常规的用例建模一般包括两个组成部分:绘制用例图和编写用例文档。

    ++++绘制用例图:用例图是UML中比较简单的一种图形,它包含两个主要组成要素,分别是执行者(Actor)和用例(Use Case)。

    ++++编写用例文档:绘制用例图只是完成了用例建模最基本也是最简单的一步,用例建模的核心在于编写用例文档,用例文档又称为用例规约或用例描述。(用例文档是用于描述用例的文档,每一个用例对应于一个用例文档,在用例文档中需要用文字的方式描述用例的执行过程,即执行者与系统的交互过程。)

    ++3.7.2UML类图

    ++++UML2.013种图形中,类图是使用频率最高的UML图之一。

    ++++类图很重要。

    ++++类图用于描述系统中所包含的类以及它们之间的相互关系,帮助人们简化对系统的理解,它是系统分析和设计阶段的重要产物,也是系统编码和测试的重要模型依据。

    ++3.7.3、类

    ++++类(Class)封装了数据和行为,是面向对象的重要组成部分,它是具有相同属性、操作、关系的对象集合的总称。(在系统中,每个类都具有一定的职责,职责指的是类要完成什么样的功能,要承担什么样的义务。)(一个类可以有多种职责,设计得好的类一般只有一种职责。)(在定义类的时候,将类的职责分解成为类的属性和操作(即方法)。)(类的属性即类的数据职责,类的操作即类的行为职责。)

    ++++设计类是面向对象设计中最重要的组成部分,也是最复杂和最耗时的部分。

    ++++在软件系统运行时,类将被实例化成对象(Object),对象对应于某个具体的事物,是类的实例(Instance)。

    ++++类图(Class Diagram)使用出现在系统中的不同类来描述系统的静态结构,它用来描述不同的类以及它们之间的关系。

    ++++在系统分析与设计阶段,类通常可以分为三种:实体类(Entity Class)、控制类(Control Class)和边界类(Boundary Class)。

    ++++实体类(Entity Class):实体类对应系统需求中的每个实体,它们通常需要保存在永久存储体中,一般使用数据库表或文件来记录,实体类集包括存储和传递数据的类,还包括操作数据的类。

    ++++控制类(Control Class):控制类用于体现应用程序的执行逻辑,提供相应的业务操作,将控制类抽象出来可以降低界面和数据库之间的耦合度。

    ++++边界类(Boundary Class):边界类用于对外部用户与系统之间的交互对象进行抽象,主要包括界面类。

    ++++在面向对象分析和设计的初级阶段,通常首先识别出实体类,绘制初始类图,此时的类图也可称为领域模型,包括实体类及其它们之间的相互关系。

    ++3.7.4、类的MUL图示

    ++++UML中,类使用包含类名、属性和操作且带有分割线的长方形来表示。

    ++++UML类图中,类一般由三部分组成:

    --第一部分:类名:每个类都必须有一个名字,类名是一个字符串。

    --第二部分:类的属性(Attributes):属性是指类的性质,即类的成员变量。一个类可以有任意多个属性,也可以没有属性。(表示方式: 可见性 名称:类型[=缺省值]

    --第三部分:类的操作(Operations):操作是类的任意一个实例对象都可以使用的行为,是类的成员方法。(表示方式: 可见性 名称(参数列表)[: 返回类型]

    ++3.7.5、类与类之间的关系

    ++++在软件系统中,类并不是孤立存在的,类与类之间存在各种关系,对于不同类型的关系,UML提供了不同的表示方式:关联关系、依赖关系、泛化关系。

    ++++【关联(Association)关系】:是类与类之间最常用的一种关系,它是一种结构化关系,用于表示一类对象与另一类对象之间有联系。(在UML类图中,用实线连接有关联关系的对象所对应的类。)(在使用编程语言实现关联关系时,通常将一个类的对象作为另一个类的成员变量。)(在UML中,关联关系通常包含:双向关联、单向关联、自关联、多重性关联、聚合关系、组合关系。)

    --双向关联:默认情况下,关联是双向的。(例如:顾客购买商品并拥有商品,反之,卖出的商品总有某个顾客与之相关联。)

    --单向关联:类的关联关系也可以是单向的,单向关联用带箭头的实线表示。(例如:顾客拥有地址,则Customer类与Address类具有单向关联关系。)

    --自关联:在系统中可能会存在一些类的属性对象类型为该类本身,这种特殊的关联关系称为自关联。(例如:一个节点类(Node)的成员又是节点Node类型的对象。)

    --多重性关联:又称为重数性(Multiplicity)关联关系,表示两个关联对象在数量上的对应关系。在UML中,对象之间的多重性可以直接在关联直线上用一个数字或一个数字范围表示。(例如:一个界面可以拥有零个或多个按钮,但是一个按钮只能属于一个界面。)

    --聚合(Aggregation)关系:表示整体与部分的关系。在聚合关系中,成员对象是整体对象的一部分,但是成员对象可以脱离整体对象独立存在。在UML中,聚合关系用带空心菱形的直接表示。(例如:汽车发动机是汽车的组成部分,但是汽车发动机可以独立存在。)(在代码实现聚合关系时,成员对象通常作为构造方法、Setter方法或业务方法的参数注入到整体对象中。)

    --组合(Composition)关系:表示类之间整体和部分的关系,但是在组合关系中整体对象可以控制成员对象的生命周期,一旦整体对象不存在,成员对象也将不存在,成员对象与整体对象之间具有同生死的关系。在UML中,组合关系用带实心菱形的直线表示。(例如:人的头与嘴巴,嘴巴是头的组成部分之一,而且如果头没了,嘴巴也就没了,因此头和嘴巴是组合关系。)(在代码实现组合关系时,通常在整体类的构造方法中直接实例化成员类。)

    ++++【依赖(Dependency)关系】:是一种使用关系,特定事物的改变有可能会影响到使用该事物的其他事物,在需要表示一个事物使用另一个事物时使用依赖关系。大多数情况下,依赖关系体现在某个类的方法使用另一个类的对象作为参数。在UML中,依赖关系用带箭头的虚线表示,由依赖的一方指向被依赖的一方。(例如:驾驶员开车,在Driver类的drive()方法中将Car类型的对象myCar作为一个参数传递,以便在drive()方法中能够调用myCarmove()方法,且驾驶员的drive()方法依赖车的move()方法,因此类Driver依赖类Car。)

     

    (在系统实施阶段,依赖关系通常通过三种方式来实现:第一种,最常用方式,将一个类的对象作为另一个类中方法的参数;第二种,在一个类的方法中将另一个类的对象作为其局部变量;第三种,在一个类的方法中调用另一个类的静态方法。)

    ++++【泛化(Generalization)关系】:也就是继承关系,用于描述父类与子类之间的关系,父类又称作基类或超类,子类又称作派生类。在UML中,泛化关系用带空心三角形的直线来表示。在代码实现时,我们使用面向对象的继承机制来实现泛化关系,如在C++/C#中使用冒号“:”来实现。(在Java语言中使用extends关键字。)

    ++++【接口与实现关系】:在很多面向对象语言中都引入了接口的概念,如JavaC#等。在接口中,通常没有属性,而且所有的操作都是抽象的,只有操作的声明,没有操作的实现。UML中用于类的表示法类似的方式表示接口。接口之间可以有类之间关系类似的继承关系和依赖关系,但是接口和类之间还存在一种实现(Realization)关系,在这种关系中,类实现了接口,类中的操作实现了接口中所声明的操作。在UML中,类与接口之间的实现关系用带空心三角形的虚线来表示。



    ++3.7.6UML发展现状与实际应用

    ++++UML的应用领域很广泛,实际上除了软件界可以使用之外,其他行业也可以使用,甚至有用UML的方法绘制的军事战略部署图,当然最主要的还是应用于计算机领域。它可以用于各种类型的软件开发,无论是制造业、游戏开发、医疗卫生系统、还是OAEAIDSSERP...都可以使用到UML

    ++++UML建模语言对于使用面向对象技术开发的系统更加合适,当然在需求分析等阶段对所有的应用系统都实用。像一些流程化很强的系统,或者小型的项目有时候没有必要一定使用UML。像敏捷开发中就提到系统的开发人员应该从技术和工具灵活的选择,找到最合适的工具,像做一个小软件,就不需要用到UML来进行建模。

    ++++UML主要用于系统的分析和设计阶段,现在大部分的UML case工具都能自动生成一些程序代码,实际上也可以用于一些基本的系统实施阶段,同时从UML分析中可以得到一些测试用例,另外UML对系统的维护与设计也有所帮助,好的UML模型让维护人员在发现问题后可以很快找到问题的根源,在项目开发的全过程中都可以见到UML,但是主要还是分析和设计。

    ++++正确使用UML来分析与设计系统。采用UML作为建模语言是完全必要的:首先,各种各样的面向对象建模语言都是相互独立的,而UML可以消除一些潜在的不必要的差异,以免用户混淆;第二,通过统一语义和符号表示,能够稳定面向对象技术市场,使项目根植于一个成熟的标准建模语言,从而可以大大拓展所研制与开发的软件系统的适用范围,并大大提高其灵活程度。



    ##3.8UML类图详解

    ++3.8UML类图详解

    ++++类图(Class Diagrams)是根据系统中的类以及各类之间的关系描述系统的静态视图。类图不仅显示系统内信息的结构,还描述系统内这些信息的行为。类图的一个重要目的是为其他图(如顺序图、交互图)定义一个基础。类图由多个类以及这些类之间的关系组成。

    ++++在系统设计阶段,类图直接引导面向对象的编程语言实现类。类图是生成代码的核心要图。如果类图设计得好,整个系统的代码框架可以由类图自动生成,大大简化了系统编码所耗费的时间。


    ++3.8.1、类(Class

    ++++类是对象的蓝图。

    ++3.8.2、接口(Interface

    ++++接口是一系列操作的集合,它指定了一个类所提供的服务。

    ++3.8.3、类图关系

    ++++类图关系:依赖(Dependency)、关联(Association)、聚合(Aggregation)、组合(合成)(Composition)、泛化(Generalization)、实现(Realization)等。

    ++++【依赖(Dependency)】:对于两个相对独立的类,当一个类负责构造另一个类的实例,或者依赖另一个类时,这两个类之间主要体现为依赖关系。

    ++++【关联(Association)】:对于两个相对独立的类,当一个类的实例与另一个类的实例存在固定的对应关系时,这两个类之间为关联关系。

    ++++【聚合(Aggregation)】:当系统A被加入到系统B中,成为系统B的组成部分时,系统B和系统A之间为聚合关系。(聚合(Aggregation)关系是关联关系的一种,是强的关联关系。)(聚合是整体和个体之间的关系。例如:大雁类可以脱离雁群类而独立存在。)

    ++++【组合(Composition)】:组合是聚合的一种特殊形式,暗示“局部”在“整体”内部的生存期职责。(例如:翅膀类不可以脱离大雁类而独立存在。)

    ++++【泛化(Generalization)】:表示类与类之间的继承关系,接口与接口之间的继承关系,或类对接口的实现关系。(泛化表示一个更泛化的元素和一个更具体的元素之间的关系。)

    ++++【实现(Realization)】:实例关系指向实现接口,箭头指向接口。

    ++++这几种关系都是语义级别的,从代码层面并不能完全区分各种关系,其表现的强弱程度: 组合>聚合>关联>依赖。

    ++++【聚合VS组合】:聚合和组合都是一种结合关系,只是额外具有整体-部分的含义。(生命周期不同:聚合关系中,整件不会拥有部件的生命周期,所以整件删除时,部件不会被删除,多个整件可以共享同一个部件;组合关系中,整件拥有部件的生命周期,整件删除时,部件一定会跟着删除,多个整件不可以同时共享同一个部件。)(聚合关系是“has-a”关系,组合关系是“Contains-a”关系。)

    ++++【关联VS聚合】:关联和聚合的区别主要在语义上,关联的两个对象之间一般是平等的。(关联:例如,你是我的朋友。)(关联是一种结构化的关系,指一种对象和另一种对象有联系。)

    ++++【关联VS依赖】:关联关系中,体现的是两个类、或者类与接口之间语义级别的一种强依赖关系,比如我和我的朋友。这种关系比依赖更强、不存在依赖关系的偶然性、关系也不是临时性的,一般是长期性的,而且双方的关系一般是平等的。(依赖关系中,就是一个类A使用到了另一个类B,而这种使用关系是具有偶然性的、临时性的、非常弱的,但是B类的变化会影响到A。)


    #立钻哥哥Unity学习空间:https://blog.csdn.net/VRunSoftYanlz/

    ++立钻哥哥推荐的拓展学习链接(Link_Url

    ++++立钻哥哥Unity 学习空间: http://blog.csdn.net/VRunSoftYanlz/

    ++++设计模式简单整理https://blog.csdn.net/vrunsoftyanlz/article/details/79839641

    ++++U3D小项目参考https://blog.csdn.net/vrunsoftyanlz/article/details/80141811

    ++++UML类图https://blog.csdn.net/vrunsoftyanlz/article/details/80289461

    ++++Unity知识点0001https://blog.csdn.net/vrunsoftyanlz/article/details/80302012

    ++++U3D_Shader编程(第一篇:快速入门篇)https://blog.csdn.net/vrunsoftyanlz/article/details/80372071

    ++++U3D_Shader编程(第二篇:基础夯实篇)https://blog.csdn.net/vrunsoftyanlz/article/details/80372628

    ++++Unity引擎基础https://blog.csdn.net/vrunsoftyanlz/article/details/78881685

    ++++Unity面向组件开发https://blog.csdn.net/vrunsoftyanlz/article/details/78881752

    ++++Unity物理系统https://blog.csdn.net/vrunsoftyanlz/article/details/78881879

    ++++Unity2D平台开发https://blog.csdn.net/vrunsoftyanlz/article/details/78882034

    ++++UGUI基础https://blog.csdn.net/vrunsoftyanlz/article/details/78884693

    ++++UGUI进阶https://blog.csdn.net/vrunsoftyanlz/article/details/78884882

    ++++UGUI综合https://blog.csdn.net/vrunsoftyanlz/article/details/78885013

    ++++Unity动画系统基础https://blog.csdn.net/vrunsoftyanlz/article/details/78886068

    ++++Unity动画系统进阶https://blog.csdn.net/vrunsoftyanlz/article/details/78886198

    ++++Navigation导航系统https://blog.csdn.net/vrunsoftyanlz/article/details/78886281

    ++++Unity特效渲染https://blog.csdn.net/vrunsoftyanlz/article/details/78886403

    ++++Unity数据存储https://blog.csdn.net/vrunsoftyanlz/article/details/79251273

    ++++Unity中Sqlite数据库https://blog.csdn.net/vrunsoftyanlz/article/details/79254162

    ++++WWW类和协程https://blog.csdn.net/vrunsoftyanlz/article/details/79254559

    ++++Unity网络https://blog.csdn.net/vrunsoftyanlz/article/details/79254902

    ++++C#事件https://blog.csdn.net/vrunsoftyanlz/article/details/78631267

    ++++C#委托https://blog.csdn.net/vrunsoftyanlz/article/details/78631183

    ++++C#集合https://blog.csdn.net/vrunsoftyanlz/article/details/78631175

    ++++C#泛型https://blog.csdn.net/vrunsoftyanlz/article/details/78631141

    ++++C#接口https://blog.csdn.net/vrunsoftyanlz/article/details/78631122

    ++++C#静态类https://blog.csdn.net/vrunsoftyanlz/article/details/78630979

    ++++C#中System.String类https://blog.csdn.net/vrunsoftyanlz/article/details/78630945

    ++++C#数据类型https://blog.csdn.net/vrunsoftyanlz/article/details/78630913

    ++++Unity3D默认的快捷键https://blog.csdn.net/vrunsoftyanlz/article/details/78630838

    ++++游戏相关缩写https://blog.csdn.net/vrunsoftyanlz/article/details/78630687

    ++++立钻哥哥Unity 学习空间: http://blog.csdn.net/VRunSoftYanlz/


    --_--VRunSoft : lovezuanzuan--_--

    展开全文
  • mac下的UML建模工具 argoUML

    热门讨论 2013-01-23 23:04:11
    mac下的UML建模工具 argoUML
  • UML笔记

    千次阅读 2010-12-15 09:09:00
    uml基础与应用(第0讲) 2课程内容 2参考教材 2uml概述 2内容提纲 2面向对象技术(第一部分) 3模型与可视化建模 4什么是uml 4uml发展历史 5软件过程 6UML工具(第1讲) 6UML的构成 7UML示例(第3讲) 11UML在软件开发...
  • UML总结

    热门讨论 2018-11-29 21:17:57
    面向对象技术  面向对象的三个特性 封装性、多态性、继承性   模型和可视化建模 ...模型:系统、目标、组成、约束条件、变量、关系 ...分解、抽象、泛化(继承)、...uml基本构造块:1.事物 2.关系 3.图(核心内...
  • 命令:java -jar UMLParserClass.jar ./TestCases/test4 classDiagram.png Argument1:包含Java文件的testcase文件夹的完整路径参数2:输出图像文件的名称 YouTube视频的URL:将UML Parser与Cloud Scale Web应用程序...
  • 工具官网: 下载页面 yEd有点儿类似visio,功能上还是...下载后,解压至目录,然后通过java命令运行 java -jar yed.jar 1.新建绘图板 2.找到uml工具位置 在右上角有个Palette框,找到UML即可,拖动图标至中央 3.UM...
  • 一、建立命令队列;二、可以将命令记入日志;三、接收请求的一方可以拒绝;四、添加一个新命令类不影响其它类; 命令模式把请求一个操作的对象与知道怎么操行一个操作的对象分开 命令模式感觉就是一个领导接受...
  • 二、命令模式UML 三、JAVA代码实现 package com.amosli.dp.behavior.command; public abstract class Command { protected Receiver invoker; public Command(Receiver invoker) { this....
  • UML基础教程

    千次阅读 2019-09-09 23:35:43
    作者:许东明 ... 最近更新时间:2019/9/9 一、前言 ...对UML1.5各种模型图的构成和功能进行说明 ...1.1UML概述 ...1.1.1UML简介 ...UML (Unified Modeling Language)为面向对象软件设计提供统一的、标准的...UML的定义包括UML...
  • 初识UML

    热门讨论 2015-10-25 08:48:55
    正在看UML视频,从前几集中了解到UML基础知识,总结如下:  UML(Unified Modeling Language)不是程序设计语言,不是形式化语言,它是可视化的建模语言。UML是支持模块化和软件系统开发的图形化语言,用“图”的...
  • UML::UML核心元素

    千次阅读 2012-08-02 16:26:49
    我对UML的理解:软件工程的东西。(有点模糊,不是很懂。)   建模:个人理解——对现实的一种抽象,对现实的简化,模型比现实更好理解。即是抽象。   UML核心元素: 版型(stereotype):版型也称类型、构造型...
  • uml学习入门

    2021-03-02 21:25:00
    面向对象与面向过程的区别面向对象"什么做什么"与面向过程"做什么"最大的区别在于,面向对象的重点在于谁发出了什么命令,而面向过程只关心一个命令.面向对象以对象为基础,以事件或消息驱动对象执行处理.它不像面向...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 28,924
精华内容 11,569
关键字:

uml命令