Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
A Game: Get-15 • The game starts with nine numbers 1,2,3,4,5,6,7,8 and 9 • You and your opponent take alternate turns, each taking a number • Each number can be taken only once: If you opponent has selected a number, you can no longer take it • The first person to have any three numbers that total 15 wins the game • Example: You: 1 5 3 8 Opponent: Bernd Bruegge & Allen H. Dutoit 6 9 7 2 Object-Oriented Software Engineering: Using UML, Patterns, and Java Opponent Wins! 5 Characteristics of Get-15 • Hard to play • The game is especially hard, if you are not allowed to write anything down • Why? • All the numbers must be scanned to see if you have won/lost • It is hard to see what the opponent will take if you take a certain number • The choice of the next number depends on all the previous numbers (your and your opponent’s numbers) • Not easy to devise a simple strategy. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 6 Another Game: Tic-Tac-Toe Source: http://boulter.com/ttt/index.cgi Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 7 A Draw Sitation Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 8 Strategy for determining a winning move Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 9 Winning Situations for Tic-Tac-Toe Winning Patterns Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 10 Tic-Tac-Toe is “Easy” Why? Reduction of complexity through patterns and symmetry Patterns: Knowing the following three patterns, the player can anticipate the opponents move. Symmetry: The player needs to remember only these three patterns to deal with 8 different game situations The player needs to memorize only 3 opening moves and their responses. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 11 Get-15 and Tic-Tac-Toe are identical problems ♦ ♦ ♦ Any sequence of three numbers that wins the Get-15 game also wins at Tic-Tac-Toe Any Tic-Tac-Toe solution is also a solution the to Get-15 problem To see the relationship between the two games, we simply arrange the 9 digits into the following pattern 8 1 6 3 5 7 4 9 2 . Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 12 You: 1 Opponent: 6 8 1 6 3 5 7 4 9 2 Bernd Bruegge & Allen H. Dutoit 5 3 9 8 7 2 8 1 6 3 5 7 4 9 2 Object-Oriented Software Engineering: Using UML, Patterns, and Java 13 Stays simple ! • During object modeling we do many transformations and changes to the object model • It is important to make sure the system model stays simple during these model transformations • After all, the goal of a model is to be an abstraction, that is, a simplification, not a complication • Design patterns keep the system model simple. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 14 Heuristics for Good Models • Modeling must address our mental limitations: • Our short-term memory has only limited capacity (7+-2) • Good models deal with this limitation, because … … they do not tax the mind • A good model requires a minimal mental effort to understand … they reduce complexity • Use of patterns • Use of symmetries … they use abstractions • Taxonomies … they have organizational structure • Memory limitations are overcome with an appropriate representation (“natural model”). Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 15 Outline of the Lecture Two games Patterns and symmetry help to win the game Heuristics for good models • Reducing the complexity of models • Patterns covered in this lecture • • • • Composite: Model dynamic aggregates Facade: Interfacing to subsystems Adapter: Interfacing to existing systems (legacy systems) Bridge: Interfacing to existing and future systems • Next lecture (January 8) • • • • Factory and Abstract Factory Proxy Observer Strategy Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 16 Review: Design pattern A design pattern is… …a reusable template for solving a recurring design problem • Basic idea: Don’t re-invent the wheel! … design knowledge • Knowledge on a higher level than classes, algorithms or data structures (linked lists, binary trees...) • Lower level than application frameworks …an example of modifiable design • Learning how to design starts by studying other designs. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 17 Why are modifiable designs important? A modifiable design… …enables an iterative and incremental development • concurrent development • risk management • flexibility to change … minimizes the introduction of new problems when fixing old ones … allows to easily add more functionality after the delivery of the system Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 18 What makes a design modifiable? • Low coupling and high cohesion • Clear dependencies • Explicit assumptions How do design patterns help? • They are generalized from existing systems • They provide a shared vocabulary to designers • They provide examples of modifiable designs • Abstract classes • Delegation Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 19 Recall: Finding Objects • The hardest problems in object-oriented system development are: • Identifying objects • Decomposing the system into objects • Requirements Analysis focuses on application domain: • Object identification • System Design addresses both, application and implementation domain: • Subsystem identification • Object Design focuses on implementation domain: • Additional solution objects. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 20 Recall: Techniques for Finding Objects • Requirements Analysis • Start with Use Cases. Identify participating objects • Textual analysis of flow of events (find nouns, verbs, ...) • Extract application domain objects by interviewing client (application domain knowledge) • Find objects by using general knowledge • System Design • Subsystem decomposition • Try to identify architectural style • Object Design • Find additional objects by applying implementation domain knowledge • Try to identify design patterns. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 21 COMPOSITE PATTERN Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 22 What is common between these definitions? • Definition Software System • A software system consists of subsystems which are either other subsystems or collection of classes • Definition Software Lifecycle • A software lifecycle consists of a set of development activities which are either other actitivies or collection of tasks. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 23 What is common between these definitions? • Definition Software System • A software system consists of subsystems which are either other subsystems or collection of classes • Composite: Subsystem (A software system consists of subsystems which consists of subsystems, which consists of subsystems, which...) • Leaf node: Class • Definition Software Lifecycle • A software lifecycle consists of a set of development activities which are either other actitivies or collection of tasks • Composite: Activity (A software lifecycle consists of activities which consist of activities, which consist of activities, which....) • Leaf node: Task. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 24 Introducing the Composite Pattern • Tree structures that represent part-whole hierarchies with arbitrary depth and width can be used in the solution of many problems • The Composite Pattern lets a client treat individual objects and compositions of these objects uniformly Component Client Operation() Leaf Operation() * Composite Operation() AddComponent() RemoveComponent() GetChildren() Children Modeling a Software System with a Composite Pattern Software System User * Class Subsystem Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java Children 26 Modeling the Software Lifecycle with a Composite Pattern Software Lifecycle Manager * Task Activity Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java Children 27 The Composite Patterns models Dynamic Aggregates Fixed Structure: Car * * Doors Wheels Battery Engine Organization Chart (variable aggregate): * University * School Department Dynamic tree (recursive aggregate): Program Composite Pattern * Compound Statement Bernd Bruegge & Allen H. Dutoit * Block Simple Statement Object-Oriented Software Engineering: Using UML, Patterns, and Java 28 Graphic Applications use the Composite Pattern • The Graphic Class represents both primitives (Line, Circle) and containers (Picture). Graphic Client * Draw() Line Draw() Bernd Bruegge & Allen H. Dutoit Circle Draw() Picture Draw() Add(Graphic g) RemoveGraphic) GetChild(int) Object-Oriented Software Engineering: Using UML, Patterns, and Java Children 29 Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 30 The Java‘s AWT library can be modeled with the component pattern Graphics Component * getGraphics() Text Component TextField Bernd Bruegge & Allen H. Dutoit Button Label Container add(Component c) paint(Graphics g) TextArea Object-Oriented Software Engineering: Using UML, Patterns, and Java 31 Reducing the Complexity of Models • Modeling is about communication • To a human being as well as to a tool • To communicate a complex model to a human being we use navigation and reduction of complexity • Navigate through the model so the user can follow it • Start with a very simple model • Identify the key abstractions • Then decorate the model with additional classes • To reduce the complexity of the model further • Look for inheritance (taxonomies) • If the model is too complex, taxonomies should be placed in separate UML packages • Then identify or introduce patterns in the model • Make sure to use the name of the patterns. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 32 Example: Modeling a Project Equipment Project Facility * Resource Schedule * Outcome Work Breakdown Structure * * consumes Organization desWork cribes Package * produces * * Fund Work depends * Organizational responUnit * sible plays for Role Set of Work Work Products Product Activity Project Internal Work Product Deliverable Bernd Bruegge & Allen H. Dutoit Task Participant Staff Project Function Object-Oriented Software Engineering: Using UML, Patterns, and Java Department 33 Team How to reduce the Complexity of the Model 1. Look for the key abstractions • Project, Outcome, Schedule, Work, Resource 2. Identify patterns: For example, the project model has 3 composite patterns * 3. Find all the application domain taxonomies • Start with the taxonomies for the key abstractions 4. Key abstractions, patterns and/or taxonomies are candidates for separate UML packages. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 34 1. Find the Key Abstractions in the Model Key Abstractions Equipment Project Facility * Resource Schedule * Outcome Work Breakdown Structure * * consumes Organization desWork cribes Package * produces * * Fund Work depends * Organizational responUnit * sible plays for Role Set of Work Work Products Product Activity Project Internal Work Product Deliverable Bernd Bruegge & Allen H. Dutoit Task Participant Staff Project Function Object-Oriented Software Engineering: Using UML, Patterns, and Java Department 35 Team Key Abstractions in the Project Model Project Outcome Bernd Bruegge & Allen H. Dutoit Schedule Work Object-Oriented Software Engineering: Using UML, Patterns, and Java Resource 36 2. Find Patterns used in the Model Equipment Project Facility * Resource Composite Patterns Schedule * Outcome Work Breakdown Structure * * consumes Organization desWork cribes Package * produces * * Fund Work depends * Organizational responUnit * sible plays for Role Set of Work Work Products Product Activity Project Internal Work Product Deliverable Bernd Bruegge & Allen H. Dutoit Task Participant Staff Project Function Object-Oriented Software Engineering: Using UML, Patterns, and Java Department 37 Team Composite Patterns in the Project Model Outcome * * * Set of Work Products Organizational Unit Work Work product Bernd Bruegge & Allen H. Dutoit Activity Task Object-Oriented Software Engineering: Using UML, Patterns, and Java Participant Staff 38 3. Find the Taxonomies used in the Model Taxonomies Equipment Project Facility * Resource Schedule * Outcome Work Breakdown Structure * * consumes Organization desWork cribes Package * produces * * Fund Work depends * Organizational responUnit * sible plays for Role Set of Work Work Products Product Activity Project Internal Work Product Deliverable Bernd Bruegge & Allen H. Dutoit Task Participant Staff Project Function Object-Oriented Software Engineering: Using UML, Patterns, and Java Department 39 Team Step 4: Package based on Key Abstractions Project Project Outcome Bernd Bruegge & Allen H. Dutoit Schedule Work Object-Oriented Software Engineering: Using UML, Patterns, and Java Resource 40 Step 4 continued: Additional Packages based on Patterns Work Outcome Organizational Unit Work Outcome * * * Set of Work Products Organization Work product Bernd Bruegge & Allen H. Dutoit Activity Task Object-Oriented Software Engineering: Using UML, Patterns, and Java Participant Staff 41 Step 4 continued: Additional UML Packages based on Taxonomies Resource Resource Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 42 Summary • Design patterns are template solutions for common design problems such as • separating an interface from a number of alternate implementations • Accessing a set of legacy classes • protecting a caller from changes associated with specific platforms • A design pattern consists of a small number of classes • uses delegation and inheritance • provides a modifiable design solution • These classes can be adapted and refined for the specific system under construction • To provide the reuse of existing solutions • Customization of the system. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 50 Additional Readings • E. Gamma et.al., Design Patterns, 1994. • M. Fowler, Analysis Patterns: Reusable Object Models, 1997 • F. Buschmann et. Al., Pattern-Oriented Software Architecture: A System of Patterns, 1996 • T. J. Mowbray & R. C. Malveau, CORBA Design Patterns, 1997 • S. W. Ambler, Process Patterns: Building Large-Scale Systems Using Object Technology, 1998. • Dependency management: P. Feiler & W. Tichy, “Propagator: A family of patterns,” in Proceedings of TOOLS-23'97, Santa Barbara, CA, Aug, 1997. • Configuration management: W. J. Brown et. Al., AntiPatterns and Patterns in Software Configuration Management, 1999. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 51 Backup Slides Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 52 Notation used in the Design Patterns Book • Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software, Addison Wesley, 1995 • Based on OMT (a precursor to UML). Notational differences between the OMT notation and UML: Attributes come after the Operations Associations are called acquaintances Multiplicities are shown as solid circles Dashed line: Instantiation Association (Class can instantiate objects of associated class) (In UML it denotes a dependency) • UML Note is called Dog-ear box (connected by dashed line to class operation): Pseudo-code implementation of operation. • • • • Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 53