12.面向重用的软件开发

2020-02-27 54浏览

  • 1.面向重用的软件开发    Software reuse Component-Based Software Development Design Patterns CASESTUDY:How to apply Strategy Pattern Component-level Design Basic Design Principles CASESTUDY:How to get a “good” component
  • 2.Reuse landscape Design patterns Component frameworks Component-based development Service-oriented systems Application Product lines Aspect-oriented Software development COTS integration Legacy system wrapping Configurable vertical applications Program libraries Program generators
  • 3.Component-Based Software Development CBSD的产生背景： 1）COTS(Commercial-Off-The-Shelf，商用现成品或技术”或“商用货 架产品”）构件质量的提高和种类的增加； 2）要求降低系统开发和维护成本的经济压力； 3）构件集成技术的出现； 4）软件开发组织内可以用于新系统开发的已有软件制品的数量增加。 CBSD整个过程从需求开始，由开发团队使用传统的需求获取技术建立系 统的需求规约。在完成体系结构设计后，并不立即开始详细设计，而是确 定哪些部分可由构件组装而成。此时开发人员面临的设计决策包括: “是否存在满足某种需求的COTS 构件”， “是否存在满足某种需求的内部开发的可复用构件”， “这些可用构件的接口与体系结构的设计是否匹配”等。 对于那些无法通过已有构件满足的需求，就只能采用传统的或面向对象的 软件工程方法开发新构件。
  • 4.Component-Based System Development Lifecycle The development cycle compared with the waterfall model qualification…… adaptation……composition…… update
  • 5.Qualification（鉴定） ——通过接口以及其它约束判断COTS 构件是否可在新系统中复用。 构件鉴定分为发现和评估两个阶段。 发现阶段需要确定COTS 构件的各种属性，如构件接口的功能性（构件能够提供 什么服务）及其附加属性（如，是否遵循某种标准）、构件的质量属性（如，可靠 性）等。 评估阶段根据COTS 构件属性以及新系统的需求判断构件是否可在系统中复用。 评估方法常常涉及分析构件文档、与构件已有用户交流经验、甚至开发系统原型。 构件鉴定有时还需要考虑非技术因素，如构件提供商的市场占有率、构件开发商的 过程成熟度等级等。
  • 6.Adaptation（适配）  独立开发的可复用构件满足不同的应用需求，并对运行上下文做出了某些假设。  系统的软件体系结构定义了系统中所有构件的设计规则、连接模式和交互模式。  如果被复用的构件不符合目标系统的软件体系结构就可能导致该构件无法正常工 作，甚至影响整个系统的运行，这种情形称为失配（mismatch）。 ——调整构件使之满足体系结构要求的行为就是构件适配。构件适配可通过白盒、 灰盒或黑盒的方式对构件进行修改或配置。  白盒方式允许直接修改构件源代码； 灰盒方式不允许直接修改构件源代码，但提供了可修改构件行为的扩展语言或编 程接口；  黑盒方式是指调整那些只有可执行代码且没有任何扩展机制的构件。如果构件无 法适配，就不得不寻找其它适合的构件。 
  • 7.Composition（组装） 构件必须通过某些良好定义的基础设施才能组装成目标系统。体系风格决定了构 件之间连接或协调的机制，是构件组装成功与否的关键因素之一。典型的体系风 格包括黑板、消息总线、对象请求代理等。 CORBA Updation（更新） 基于构件的系统演化往往表现为构件的替换或增加，其关键在于如何充分测试新 构件以保证其正确工作且不对其它构件的运行产生副面影响，对于由COTS 构件 组装而成的系统，其更新的工作往往由提供COTS 构件的第三方完成。
  • 8.Types of composition（构件的组装类型）    Sequential composition where the composed components are executed in sequence. This involves composing the provides interfaces of each component. Hierarchical composition where one component calls on the services of another. The provides interface of one component is composed with the requires interface of another. Additive composition where the interfaces of two components are put together to create a new component.
  • 9.组装时可能出现的问题：接口不一致性    Parameter incompatibility where operations have the same name but are of different types. Operation incompatibility where the names of operations in the composed interfaces are different. Operation incompleteness where the provides interface of one component is a subset of the requires interface of another.
  • 10.需求举例：根据电话号码查询并打印区域地图 string location(string pn) string owner(string pn) Phone Database(string command) addressFinder string propertyType(string pn) displayMap(string postCode,scale) map DB (string command) mapper printMap(string postCode,scale)
  • 11.Adapter components    Address the problem of component incompatibility by reconciling the interfaces of the components that are composed. Different types of adapter are required depending on the type of composition. An addressFinder and a mapper component may be composed through an adapter that strips the postal code from an address and passes this to the mapper component. address = addressFinder.location (phonenumber) ; postCode = postCodeStripper.getPostCode (address) ; mapper.displayMap(postCode, 10000)
  • 12.Design patterns（设计模式）     A pattern is a description of the problem and the essence of its solution. A design pattern is a way of reusing abstract knowledge about a problem and its solution. It should be sufficiently abstract to be reused in different settings. Patterns often rely on object characteristics such as inheritance and polymorphism.
  • 13.设计模式分类 按作用分类 类 范 围 对 象 创建型 结构型 行为型 Factory Method A d a p t e r (类) Interpreter Template Method Abstract Factory Builder Prototype Singleton A d a p t e r (对象) Bridge Composite Decorator Facade Flyweight Proxy Chain of Responsibility Command Iterator Mediator Memento Observer State Strategy Vi s i t o r
  • 14.Design pattern： Abstract Factory（抽象工厂） 提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类
  • 15.
  • 16.
  • 17.
  • 18.Designpattern:Composite 意图   将对象组合成一种树结构，以表示部分—整体的层次关系。组 合模式用于将单个对象有机地组合到一起。 动机    一些部件对象经过组合构成的复合部件对象仍然具有单个部件 对象的接口，这样的复合部件对象被称为“容器(container)” 复合部件与单个部件具有同样的接口，所有接口包含两部分： 单个部件的功能、管理子部件的功能 递归组合
  • 19.Composite Structure
  • 20.Composite Example
  • 21.Design pattern：Strategy  动机   定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换。本 模式使得算法可独立于使用它的客户而变化。 意图   有些算法对于某些类是必不可少的，但是不适合于硬编进类中。客户 可能需要算法的多种不同实现，允许增加新的算法实现或者改变现有 的算法实现 我们可以把这样的算法封装到单独的类中，称为strategy
  • 22.Design pattern：Strategy
  • 23.观察者模式（Observer pattern）：意图+动机 意图  定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变 时, 所有依赖于它的对象都得到通知并被自动更新。 动机    把系统分成一些相互关联的类或者对象，如何维护这些类的实例 一致性？-- 不希望为了维护一致性而使各类紧密耦合。 这一模式中的关键对象是目标(subject)和观察者(observer)。一 个目标可以有任意数目的依赖它的观察者。一旦目标的状态发生 改变, 所有的观察者都得到通知。作为对这个通知的响应，每个 观察者都将查询目标以使其状态与目标的状态同步。 这种交互也称为发布－订阅(publish-subscribe) 。目标是通知 的发布者。它发出通知时并不需知道谁是它的观察者。可以有任 意数目的观察者订阅并接收通知。
  • 24.Design pattern：Observer     Subject(目标)  目标知道它的观察者。可以有任意多个观察者观察同一个目标。  提供注册和删除观察者对象的接口。 Observer(观察者)  为那些在目标发生改变时需获得通知的对象定义一个更新接口。 ConcreteSubject(具体目标)  将有关状态存入各ConcreteObserver对象。  当它的状态发生改变时, 向它的各个观察者发出通知。 ConcreteObserver(具体观察者)  维护一个指向ConcreteSubject对象的引用。  存储有关状态，这些状态应与目标的状态保持一致。  实现Observer的更新接口以使自身状态与目标的状态保持一致。
  • 25.
  • 26.Observer pattern implementation in Java
  • 27.Observer Example
  • 28.CASE STUDY……问题   新的需求总是可能随时出现。能否设计这样的系统，它能够方便 地添加新的功能，而不至于导致对系统的重大修改。 灾难往往是由短期未臻最优的决策累积而成。在软件开发方面， 不考虑长远问题的设计往往导致维护和开发的灾难。
  • 29.引例：鸭塘游戏  Joe所在的电脑游戏公司研发了一款游戏软件，模拟池塘中各种鸭子嬉戏 （游动并且鸣叫）的场景。软件很受欢迎。
  • 30.开始时游戏的设计者采用了标准的面向对象技术 设计一个Duck超类，各种鸭子都继承这个超类。 所有的鸭子都会鸣叫和游水，所以Duck超类 实现quack()和swim()方法。由于不同种类 的鸭子样子不同，所以Duck中的display()方 法设计为抽象方法。 不同的鸭子子类通过实现display方 法显示自己的样子 其他种类的鸭子子类
  • 31.新的需求      游戏上市后的次年，竞争越来越激烈。 在外出度假一周后，公司高管们决定要对游戏作重大创新，在下周 的股东大会上，他们要让股东们“印象深刻”。 ? 高管们觉得，如果鸭子能够飞起来，则能击败同类游戏的竞争者。 Joe的上司告诉高管们，Joe可以在一周内搞定，因为他是一个 OO Programmer…
  • 32.Joe的解决方案  只要在Duck中增加一个fly() 方法就行了 其他种类的鸭子子类
  • 33.但是，一周后Joe的经理从股东大会上打来电话…   Joe，我在股东大会上，刚刚演示了游戏，他们看到屏幕上有许 多橡皮玩具鸭子在飞来飞去，你是不是故意搞笑Joe:呵呵，说实话，是偶的错，偶忘了不是所有的鸭子都会飞！ 在Duck中增加一个fly()方法，则它的所有子类就都有飞的能力了 。没想到，一个局部的修改产生了非局部的副作用。 有办法啦：   在子类RubberDuck中重写fly()方法，让它什么都不做。还有，橡 皮鸭也不会嘎嘎叫，只会吱吱叫，这样quack()方法也要改写。 但是，如果考虑再增加打猎用的仿真鸭该怎么办呢？它既不会叫也 不会飞，这样又得改写方法了。烦！看来，继承这东西有时也挺烦 人的！
  • 34.  必须要有一种清晰的方法，让一部分鸭子（而不是全部）能够飞行和鸣叫。 把fly()从Duck中分离出来，设计一个接口Flyable，该接口有一个fly()方法 ，会飞的鸭子就实现该接口。对quack()也依此处理。 这个设计方案 如何？
  • 35.对Joe新方案的分析  Joe的第二个方案解决了部分问题（不会有会飞的橡皮鸭了），但也完全 破坏了代码的重用性（每一种会飞的鸭子都必须实现fly()方法，如果要修 改飞行行为，则必须修改每种鸭子的fly()代码，设想有几十种会飞的鸭子 ）。这从另一个方面增加了维护的难度。 现在让我们将鸭子的行为从Duck类中分离出来！   我们已经知道，fly()和quack()是Duck类中不同的ducks的变化部分。 我们将这些行为从Duck类中分离出来，对于每一个方法，创建一个类的集 合来表示相应的行为。例如：对于fly()，我们建立一个类的集合，分别实 现翱翔，俯冲，起飞等。
  • 36.Duck类仍然是所有鸭 子的超类，但我们把飞 行，鸣叫行为分离出来， 将他们用另外的类结构 来表示。 不同的行为有他们自己 不同的行为有他们自己 的类集合。 的类集合。 将变化的部分分离 Duck class Flying Behaviors Quacking Behaviors
  • 37.怎么设计实现鸭子飞行和鸣叫行为的类集合？   首先，我们需要灵活性。在此之前，正是由于不灵活给我们带来了麻烦。 我们希望能够将行为指定给鸭子的某个实例。例如，我们可能希望生成一 个野鸭实例，并以某种飞行行为（例如：翱翔）对它初始化，在这之后， 我们就会想能不能动态的改变这只野鸭的行为呢？换句话说，我们应该在 Duck类中包含一个设置行为的方法，使得我们能够在运行时改变野鸭的行 为（如：由翱翔变为俯冲） 带着这个目标，让我们来看看另外一个设计原则。 对接口编程，而不是对实现编程。(Program to an interface, not an implementation)
  • 38.引入接口   对每类行为，我们用一个接口(interface)来表示。例如：用接口 FlyBehavior来表示飞行行为，用接口QuackBehavior来表示鸣叫行 为。每一个具体的行为类，是这些接口的一个实现（如：翱翔Hover ，俯冲Dive，不飞）。 这样做之后，就不是由Duck类来实现飞行和鸣叫接口了，取而代之 的是，我们设置了一组类，他们的任务就是表示某个行为，这些行为 类将用来实现上面的接口。Duck类不需要知道它们行为的实现细节
  • 39.实现鸭子的行为——用两个interface对应的两组类    采用这种设计，其他类型的对象能够复用飞行和鸣叫行为，因为这 些行为不再隐藏在Duck类中。 增加新的行为时，不需要修改已有的行为类，也不用修改使用这些 行为的Duck类。 现在我们可以不承担继承附带的包袱而享受复用的好处
  • 40.现在，怎样让鸭子有所作为？  首先，在Duck类中增加两个实例变量flyBehavior和quackBehavior 。记 住，要将他们声明为相应的接口类型哦！这样，每一个鸭对象才能够在运 行时多态地设置这些变量让他们做想做的动作（飞，嘎嘎叫等等）。Duck 类或其子类中的fly()，quack()方法将被去掉，因为我们将这些行为放在了 FlyBehavior和QuackBehavior 接口中了。我们用performFly()和 performQuack()取代原来的fly()和quack()方法。 实例变量在运行时指向一个特定的行为
  • 41.让鸭子有所作为 performFly()和performQuack()有什么用？ Public class Duck { QuackBehavior quackBehavior; 每只鸭子引用实现 QuackBehavior接口的某 FlyBehavior flyBehavior; 个类的对象 //其他属性 public void performQuack() 这只鸭子自己不叫，而是让它 { 引用的对象代替它叫。 quackBehavior.quack(); } … 这样，我们就不用关心那个对象是什么对象，我们 } 只关心它知道怎么叫！
  • 42.设置实例变量flyBehavior、 quackBehavior Public class MallardDuck extends Duck{ Public MallardDuck() { quackBehavior=new Quack(); flyBehavior=new FlyWithWings(); } 这只野鸭让 Quack类处理 鸣叫。 让FlyWithWings 类来处理飞行。 Public void display(){ System.out.println(“I’m a real Mallard duck”); } 野鸭子类的构造方法用Quack类的实例来初始化其实例的 } quackBehavior实例变量，用FlyWithWings类的实例初始 化flyBehavior实例变量。它能象真的野鸭一样鸣叫和飞行 哦！
  • 43.如何动态改变鸭子的行为 在Duck类中增加两个方法 public void setFlyBehavior(FlyBehavior fb) { flyBehavior=fb; } public void setQuackBehavior(QuackBehavior qb) { quackBehavior=qb; } 监听用户的操作，调用上述方法做出响应即可。 
  • 44.Strategy模式的结构
  • 45.Component-level Design Analysis class Req. …collect the customer’s requirements at the front counter, cost a print job, and then pass the job on to an automated production facility… e.g. computePageCost () might collaborate with a PricingTable component that contains job pricing information e.g. checkPriority() operation might collaborate with a JobQueue component to determine the types and priorities of jobs currently awaiting production Elaborated design class Design component
  • 46.Component-level design for ComputePageCost Design component Elaborated model
  • 47.Difference between a component and an object • a component is meant to be a runtime entity, whereas an object is an instance of a class. • objects are usually not thread-secure, because the designer knows (or thinks he knows) how the objects are going to be used. • So in a component,interface design is more important than it usually is in object-oriented design, and encapsulation of the state is enforced. • Objects exist at runtime, but classes are really design entities. • Components are deployed independently, and it is impossible to predict how the component is going to be used.
  • 48.Component Level Design Step 1. Identify all design classes that correspond to the problem domain. Step 2. Identify all design classes that correspond to the infrastructure domain. Step 3. Elaborate all design classes that are not acquired as reusable components. Step 3a. Specify message details when classes or component collaborate. Step 3b. Identify appropriate interfaces for each component. Step 3c. Elaborate attributes and define data types and data structures required to implement them. Step 3d. Describe processing flow within each operation in detail. Step 4. Describe persistent data sources (databases and files) and identify the classes required to manage them. Step 5. Develop and elaborate behavioral representations for a class or component. Step 6. Elaborate deployment diagrams to provide additional implementation detail. Step 7. Factor every component-level design representation and always consider alternatives.
  • 49.举例：How to get a “good” component 初始需求：编写一个从键盘读入字符并输出到打印机的程序 copy char Read Keyboard char Write Printer public class Copier { public static void Copy() { int c; while((c=Keyboard.Read())!=-1) Printer.Write(c) } }
  • 50.） 初始需求：编写一个从键盘读入字符并输出到打印机的程序 扩展需求：增加从纸带机读入信息的功能…… public class Copier { //remember to reset this flag public static bool ptFlag=false; public static void Copy() { int c; while((c=(ptFlag?PaperTape.Read() :Keyboard.Read()))!=-1) Printer.Write(c) } }
  • 51.初始需求：编写一个从键盘读入字符并输出到打印机的程序 扩展需求：增加从纸带读入机输入的功能 增加向纸带穿孔机输出的功能…… public class Copier { //remember to reset these flags public static bool ptFlag=false; public static bool puncFlag=false; public static void Copy() { int c; while((c=(ptFlag?PaperTape.Read() :Keyboard.Read()))!=-1) punchFlag?PaperTape.Punch(c):Printer.Writer(c); } }
  • 52.Remember:need is always changing…… 改进构件设计，避免脆弱性、僵化性 public interface Reader { int Read(); } public classKeyboardReader:Reader { public int Read() {return Keyboard.Read(); } public class Copier { public static Reader reader=new KeyboardReader(); public static void Copy() { int c; while((c=(reader.Read()))!=-1) Printer.Writer(c); } }