Скачать презентацию EMTM 600 Software Development Spring 2011 Lecture Notes Скачать презентацию EMTM 600 Software Development Spring 2011 Lecture Notes

c192444c95f252fd43b044c0ca518909.ppt

  • Количество слайдов: 56

EMTM 600 Software Development Spring 2011 Lecture Notes 1 http: //www. cis. upenn. edu/~val/EMTM EMTM 600 Software Development Spring 2011 Lecture Notes 1 http: //www. cis. upenn. edu/~val/EMTM 600

Assignments for next time • Retrieve “EMTM 601 Anchor Machinery Case Study” and “EMTM Assignments for next time • Retrieve “EMTM 601 Anchor Machinery Case Study” and “EMTM 600 Case Study based on Anchor Machinery” from the course web page http: //www. cis. upenn. edu/~val/EMTM 600 From the second document read about the actors and the use cases. Based on this example, START DESIGNING YOUR OWN ENTERPRISE APPLICATION: • • • Give a 1 p overview of the context and the need for your application Give at least 4 use cases, each supported by a user story (3 -10 sentences each) Groups of 3 -4 students OK. • Read the portion of Lecture Notes 1 not discussed in class, especially the slides about “antipatterns”. Write a half-page description of another antipattern, ideally based on your experience. Groups of 3 -4 students OK. • Read from Fowler’s book, chapters 2, 4 and 6 as well as the patterns “Domain Model” (pp. 116 -124) and “Model-View Controller” (pp. 330 -332). Two days before the next lecture email me THREE QUESTIONS about things you didn’t understand. Each student. EMTM 600, Spring 2011 Val Tannen

Bibliography Patterns of enterprise application architecture by Fowler, Addison Wesley 2003. We use it Bibliography Patterns of enterprise application architecture by Fowler, Addison Wesley 2003. We use it as a textbook, has some excellent discussions, it’s more general than Java EE. Core J 2 EE patterns by Alur et al. , Prentice Hall 2003. Good outline of enterprise application patterns supported by Java EE. Enterprise Java Programming with IBM Web. Sphere, second edition, by Brown, K. et. al. , Addison Wesley 2003. Very thorough, good discussions, but totally Web. Sphere-specialized. EMTM 600, Spring 2011 Val Tannen

Bibliography Cloud computing and SOA convergence in your enterprise by Linthicum, Addison Wesley 2009. Bibliography Cloud computing and SOA convergence in your enterprise by Linthicum, Addison Wesley 2009. We use it as a textbook, my assumption is that cloud computing solutions will become widespread. SOA design patterns by Erl, Prentice Hall 2009. Collection of good experience with SOA solutions. Enterprise integration patterns by Hohpe & Woolf, Addison Wesley 2004. About messaging solutions. Complements our course to some extent. EMTM 600, Spring 2011 Val Tannen

Bibliography Design patterns by Gamma et al. , Addison Wesley 1995. Classic. But not Bibliography Design patterns by Gamma et al. , Addison Wesley 1995. Classic. But not the clearest. Pattern-oriented software architecture: a system of patterns by Buschman et al. , Wiley 1996. One of the best on software design patterns. Refactoring by Fowler et al. , Addison Wesley 1999. Excellent for the developer. Force your programmers to read it! Anti. Patterns: Refactoring Software, Architectures, and Projects in Crisis by Brown, W. et al. , Wiley 2001. Fun and excellent as a management companion. EMTM 600, Spring 2011 Val Tannen

Bibliography Planning Extreme Programming by Beck & Fowler, Addison Wesley 2000. Simple, clear, very Bibliography Planning Extreme Programming by Beck & Fowler, Addison Wesley 2000. Simple, clear, very useful also as a management companion. Test-driven development: By example by Beck, Addison Wesley 2002. Also excellent for the developer. Force your programmers to read it! Software testing in the real world by Kit, ACM Press/Addison-Wesley 1995. Not a topic in this course but excellent. . NET & J 2 EE Interoperability by Peltzer. Mc. Graw-Hill 2004 Pretty lame, but the others on this topic are worse… EMTM 600, Spring 2011 Val Tannen

Enterprise Applications • Most software development $$$ are spend on enterprise applications. Definition (M. Enterprise Applications • Most software development $$$ are spend on enterprise applications. Definition (M. Fowler): they focus on the display, manipulation, and storage of large amounts of (often complex) data and support the automation of business processes with that data. • Classification: • Transactional • Business Intelligence • Business Planning • Examples (with overlaps): Customer Relationship Management, Supply Chain Management, Sales Force Automation, Enterprise Resource Planning, Customer Profiling, Market Research, Product Profitability, Inventory Analysis; uses of Data Mining and Machine Learning, etc. EMTM 600, Spring 2011 Val Tannen

Enterprise Applications, cont’d Technological challenges: • • • Lots (>1 GB) of persistent data Enterprise Applications, cont’d Technological challenges: • • • Lots (>1 GB) of persistent data Accessed concurrently Lots (at least dozens) of user interface screens Integration with other enterprise applications Scalability Security Business challenges: • • Inconsistencies among business concepts and processes Capturing the business “logic” Speed-to-market Acceptance EMTM 600, Spring 2011 Val Tannen

Enterprise Applications, cont’d Solutions • Mainframe era: CICS-like systems • Client-server era: CORBA/C++ (late Enterprise Applications, cont’d Solutions • Mainframe era: CICS-like systems • Client-server era: CORBA/C++ (late 80’s---> present? ) CORBA/Java (mid 90’s---> present? ) • Web/server-side era: Java solutions: Java EE, Spring, Hibernate, (late 90’s--->present). NET (early 00’s--->present) Ruby on Rails, Python/Zope, Python/Django, (PHP/my. SQL? ) Important remark: CORBA, Java EE 5 (formerly J 2 EE), . NET are all component frameworks EMTM 600, Spring 2011 Val Tannen

The Java Landscape § Reference implementations freely available from Sun § Platform independence § The Java Landscape § Reference implementations freely available from Sun § Platform independence § Open specifications for powerful extensions like EE These have made Java the top choice of the open source communities (but Ruby on Rails and Python/Zope or Django want to change this!) Java is the environment of the best plug-ins for IDEs (Integrated Development Environments) like § Eclipse (a major player in open-source, lots of support from IBM) • § Last year Oracle donated the Top. Link Java Persistence technology to Eclipse! Net. Beans (supported by Sun) EMTM 600, Spring 2011 Val Tannen

Open Source Java Projects Several succesful and popular open-source projects from Apache (another major Open Source Java Projects Several succesful and popular open-source projects from Apache (another major player in open-source) are Java-related: § § § Tomcat (Java servlet “container” for the Apache Web server) Struts (Java servlet implementation framework) Jakarta-Cactus (unit testing framework for servlets, EJBs etc) An open source implementation of Java EE called JBoss is now supported by Red Hat, the Linux distribution company. JBoss has sprouted Hibernate, an open source object-relational persistence and query “service” for Java. Another interesting open source implementation of a “portion” of Java EE is dubbed “lightweight” and supported by a company called Interface 21. EMTM 600, Spring 2011 Val Tannen Spring,

More Open Source Sun has seeded several open source projects: § Glass. Fish, an More Open Source Sun has seeded several open source projects: § Glass. Fish, an open source development of a Java EE application § Open. JDK 6/7, open source releases of Java SE (Standard Edition) 6 and 7 around which contributing communities have formed. Sun has stated that eventually the whole Java SDK will become open source. Current status unclear. server Open source projects rely on open specifications of COMPONENTS EMTM 600, Spring 2011 Val Tannen

Various Definitions of “Component” 1. Various Definitions of “Component” 1. "A component is a nontrivial, nearly independent, and replaceable part of a system that fulfills a clear function in the context of a well-defined architecture. A component conforms to and provides the physical realization of a set of interfaces. " (Philippe. Krutchen? , Rational. Software? ) 2. "A runtime software component is a dynamically bindable package of one or more programs managed as a unit and accessed through documented interfaces that can be discovered at runtime. " (Gartner. Group? ) 3. "A software component is a unit of composition with contextually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to third-party composition. " (Clemens Szyperski, Component. Software) 4. "A business component represents the software implementation of an autonomous business concept or business process. It consists of the software artifacts necessary to express, implement, and deploy the concept as a reusable element of a larger business system. " (Wojtek. Kozaczynski? , SSA) From the Portland Pattern Repository EMTM 600, Spring 2011 Val Tannen

More Definitions of “Component” 5. More Definitions of “Component” 5. "A component is a unit of distributed program structure that encapsulates reuse by decoupling components from their operating environment. " (Steve Crane. See http: //www-dse. doc. ic. ac. uk/~np 2/pubs. html) 6. "A component is an object in a tuxedo. That is, a piece of software that is dressed to go out and interact with the world. " -- Michael. Feathers 7. "Software components enable practical reuse of software parts and amortization of investments over multiple applications. There are other units of reuse, such as source code libraries, design, or architectures. Therefore, to be specific, software components are binary units of independent production, acquisition, and deployment that interact to form a functioning system. " (Clemens Szyperski, Component. Software Preface) From the Portland Pattern Repository EMTM 600, Spring 2011 Val Tannen

Even More Definitions of “Component” 8. Even More Definitions of “Component” 8. "A component is a physical and replaceable part of a system that conforms to and provides the realization of a set of interfaces. . . typically represents the physical packaging of otherwise logical elements, such as classes, interfaces, and collaborations. " (Grady. Booch, Jim. Rumbaugh, Ivar. Jacobson, The UML User Guide, p. 343) 9. "Components are self-contained instances of abstract data types (ADTs) that can be plugged together to form complete applications. " (Doug. Schmidt, How to Make Software Reuse Work for You, Jan. 1999 C++ Report, p. 51) From the Portland Pattern Repository EMTM 600, Spring 2011 Val Tannen

I asked EMTM 600 students which one they prefer! The students liked the following I asked EMTM 600 students which one they prefer! The students liked the following definitions: • #4 - 5 votes • #8 - 4. 5 votes • #7 - 2. 5 votes • #6 and # 2 - 2 votes each Which one do YOU prefer? Email me! The explanation for the half-votes is that one student liked half of #7 and half of #8, thus producing the following: “A component is a physical and replaceable part of a system that conforms to and provides the realization of a set of interfaces. It typically represents the physical packaging of otherwise logical elements, such as classes, interfaces, and collaborations. To be specific, software components are binary units of independent production, acquisition, and deployment that interact to form a functioning system” EMTM 600, Spring 2011 Val Tannen

Favorite definitions for “Component” Another student liked #7 but found a related definition by Favorite definitions for “Component” Another student liked #7 but found a related definition by Bachmann in an article at http: //www. sei. cmu. edu: “A component is (1) an opaque implementation of [known!] functionality, (2) subject to third-party composition, and (3) conformant with a component model [such as Java EE!]”. Yet another student preferred to formulate his own: “A system is an assemblage of related subsystems, components and elements, which work together to enable the flow of information. A system can be defined as any assemblage which accepts an input, processes it, and produces and output. Starting at the lowest building block level, an element is a self contained package of code whose size and complexity is arbitrary. The only constraint is that is serves no real function in isolation. A component is an assemblage of elements that are assembled such that they do serve a specific, well defined function within the system. Components are defined not only by the elements that the component comprises, but by the characteristics of the component at their interfaces. Components are assembled into a system, such that the system serves a well defined business need. ” Finally, one of the students found his favorite definition at www. sabc. co. za/manual/ibm/9 agloss. htm “A reusable object or program that performs a specific function and is designed to work with other components and applications. ” EMTM 600, Spring 2011 Val Tannen

From the Portland Pattern Repository Component Framework A component framework defines a set of From the Portland Pattern Repository Component Framework A component framework defines a set of abstract interactions that define the protocols by which components cooperate -- each component takes on roles in various abstract interactions. The component framework also defines the packaging for components so that they can be instantiated and composed into legal configurations. To help framework users, a component framework provides prebuilt functionality, such as useful components or automated assembly functions that automatically instantiate and compose components to perform common tasks. EMTM 600, Spring 2011 Val Tannen

Are Components Reusable? The short answer is YES! But it’s a question of degree. Are Components Reusable? The short answer is YES! But it’s a question of degree. Cox’s Pipe Dream: In 1986, Brad Cox argued that software objects could be produced like integrated circuits: out of components. (And thus capture the benefits of Moore's law - the number of components on a silicon integrated chip doubles every year. ) Obviously, it’s not the same kind of component! An IC component has much simpler (and easier to specify in excruciating detail) interfaces than a software component. But there is a similarity: the key to reuse is modularity through welldefined interfaces: Component A 1 Component B 1 or or swap (different vendors) Component A 2 EMTM 600, Spring 2011 Val Tannen interface swap (different versions) Component B 2

Reusability in component frameworks Component frameworks such as Java EE promote more reuse because Reusability in component frameworks Component frameworks such as Java EE promote more reuse because they are structured around many OO interfaces. This is primarily horizontal reuse: (i. e. across applications): Several applications can share: • • • The same Web server (eg. Apache, MS IIS) The same RDBMS (relational database management system) (eg, Oracle, DB 2, SQL Server) The same Java EE server (eg. , JBoss, Orion, IBM Web. Sphere, BEA Web. Logic, SAP Java EE Engine, Oracle JDeveloper) The same ORB (object request broker) (eg. , IONA Orbix, Borland Visi. Broker) The same transaction processing monitor (eg. , BEA Tuxedo, IBM CICS) The same messaging system (eg. , Sun ONE MQ) This works provided the applications are vendor-neutralized through the use of the component framework interfaces (eg. , the ones used with Java EE: JDBC, J 2 C, JTA, JMS, Java IDL, etc. More about JAS (the Java Alphabet Soup) later!! Vertical reuse: within an application; harder to achieve, but domain beans (i. e. strongly standardized components) can help! EMTM 600, Spring 2011 Val Tannen

A third kind of reusability? Web Server Vendor ABC Java. EE App Server Vendor A third kind of reusability? Web Server Vendor ABC Java. EE App Server Vendor UU Edge Network Dispatcher Vendor QQ Web Server Vendor XYZ Java. EE App Server Vendor VV Purpose: load-balancing EMTM 600, Spring 2011 Val Tannen

A component framework: Java Enterprise Edition z Open specification, open architecture! z A combination A component framework: Java Enterprise Edition z Open specification, open architecture! z A combination of design patterns: architectural and more detailed y y Layers Model-view-controller Proxy Adapter, etc z An end-to-end philosophy y y User interfaces Business “logic” Interfaces to EIS (Enterprise Information Systems) Concern with EAI (Enterprise Application Integration) z Concern with performance y y High availability Security Reliability Scalabiliy EMTM 600, Spring 2011 Val Tannen

Java EE Architecture: three (or five!) tiers ( or layers) Fowler / Alur et Java EE Architecture: three (or five!) tiers ( or layers) Fowler / Alur et al. } Presentation Brown et al. Val Tannen } EMTM 600, Spring 2011 Controller/Mediator Domain Business / Domain Integration / Data Source Presentation Data Mapping Data Sources

Five Layers Presentation Layer Takes care of user interfaces: user input and output. Typically Five Layers Presentation Layer Takes care of user interfaces: user input and output. Typically uses Web browsers and HTML. More recently XML/XSLT. Most recently Ajax. All this content is typically dynamic, organized in server pages (JSP). Alternatives are browser-delivered applets or a client-side application with its own GUI. Controller/Mediator Layer Centralized points for handling presentation navigation. Separates presentation flow from the domain objects. Typically implemented as servlets. Domain Layer Defines and manipulates objects that capture the business “logic” or business abstractions. Can be implemented through session EJBs or just plain objects. Key to the robustness of the implementation (think changes!) EMTM 600, Spring 2011 Val Tannen

Five Layers, cont’d Data Mapping (aka Persistence) Layer Separates the domain layer from details Five Layers, cont’d Data Mapping (aka Persistence) Layer Separates the domain layer from details of the data sources: where the data is, what needs to be made persistent, where and how. Can be implemented through entity EJBs. Data Source Layer Access to EIS, often RDBMS but sometimes legacy. Uses J 2 EE standards such as JDBC for relational sources, JMS for asynchronous access to sources with messaging capabilities, and J 2 C (Connector) for synchronous access when available. More recently, in the context of Enterprise Application Integration (EAI) and Service Oriented Architectures (SOA), this layer also handles access to external Web Services. This five-layer organization is an architectural pattern. Design Patterns are everywhere in Java EE applications! EMTM 600, Spring 2011 Val Tannen

Static and Dynamic Web Content z static: “plain” HTML, just hypertext interaction z dynamic, Static and Dynamic Web Content z static: “plain” HTML, just hypertext interaction z dynamic, on the client side y Applets (Java) y Dynamic HTML x scripts (Java. Script/Jscript, VBScript) x forms z dynamic, on the server side y CGI (Common Gateway Interface), written in “any” language y Servlets (Java) y JSP (Java Server Pages, Sun) y ASP (Active Server Pages, MS) EMTM 600, Spring 2011 Val Tannen

Where do the layers run? Java EE application server Web server presentation controller Eg. Where do the layers run? Java EE application server Web server presentation controller Eg. , JSP Servlets browser EMTM 600, Spring 2011 domain Eg. , Session EJBs data mapping data source Eg. , Entity EJBs Eg. , JDBC DB Val Tannen

Two design (super-)patterns: MVC and ORM Java EE application server Web server presentation controller Two design (super-)patterns: MVC and ORM Java EE application server Web server presentation controller Eg. , JSP Servlets MVC: Model-View-Controller browser EMTM 600, Spring 2011 domain Eg. , Session EJBs data mapping data source Eg. , Entity EJBs Eg. , JDBC ORM: Object-Relational Mapping DB Val Tannen

Software Design Patterns • Patterns address recurring design problems that arise in specific situations. Software Design Patterns • Patterns address recurring design problems that arise in specific situations. They document existing, well-proven design experience. • Patterns provide a common vocabulary and understanding for design principles. • Patterns are a means of documenting software architectures (even better if it is done by using some precise notations such as UML (Universal Modeling Language) EMTM 600, Spring 2011 Val Tannen

Design Patterns (cont’d) • Patterns help with construction of software with defined properties, satisfying Design Patterns (cont’d) • Patterns help with construction of software with defined properties, satisfying well-understood requirements. • They help conquer complexity and heterogeneity. • Aspects of a pattern: • Context • Problem • Solution From “Pattern-oriented software architecture” by Buschmann et al. , Wiley 1996 EMTM 600, Spring 2011 Val Tannen

Links for Design Patterns • Portland Pattern Repository http: //c 2. com/ppr/ • Hosted Links for Design Patterns • Portland Pattern Repository http: //c 2. com/ppr/ • Hosted by Cunningham & Cunningham Inc. • Maintained by Ward Cunningham (of XP fame), part of “Ward’s Wiki”. • Patterns Home Page http: //hillside. net/patterns/ • Hosted by The Hillside Group EMTM 600, Spring 2011 Val Tannen

Examples(1) From “Design patterns” by Gamma et al. , Addison. Wesley 1995 z Creational Examples(1) From “Design patterns” by Gamma et al. , Addison. Wesley 1995 z Creational Patterns y Abstract Factory Provide an interface for creating families of related or dependent objects without specifying their concrete classes. y Builder Separate the construction of a complex object from its representation so that the same construction process can create different representations. y Factory Method Define an interface for creating an object, but let subclasses decide which class to instantiate. y Prototype Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype. y Singleton Ensure a class only has one instance, and provide a global point of access to it. EMTM 600, Spring 2011 Val Tannen

Examples(2) From “Design patterns” by Gamma et al. , Addison. Wesley 1995 z Structural Examples(2) From “Design patterns” by Gamma et al. , Addison. Wesley 1995 z Structural Patterns y Adapter Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces. y Bridge Decouple an abstraction from its implementation so that the two can vary independently. y Composite Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly. y Decorator Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality. EMTM 600, Spring 2011 Val Tannen

Examples(3) From “Design patterns” by Gamma et al. , Addison. Wesley 1995 z Structural Examples(3) From “Design patterns” by Gamma et al. , Addison. Wesley 1995 z Structural Patterns (cont’d) y Facade Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use. y Flyweight Use sharing to support large numbers of fine-grained objects efficiently. y Proxy Provide a surrogate or placeholder for another object to control access to it. EMTM 600, Spring 2011 Val Tannen

Examples(4) From “Design patterns” by Gamma et al. , Addison. Wesley 1995 z Behavioral Examples(4) From “Design patterns” by Gamma et al. , Addison. Wesley 1995 z Behavioral Patterns y Chain of Responsibility Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it. y Command Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations. y Interpreter Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language. y Iterator Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation. EMTM 600, Spring 2011 Val Tannen

Examples(5) From “Design patterns” by Gamma et al. , Addison. Wesley 1995 z Behavioral Examples(5) From “Design patterns” by Gamma et al. , Addison. Wesley 1995 z Behavioral Patterns (cont’d) y Mediator Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently. y Memento Without violating encapsulation, capture and externalize an object's internal state so that the object can be restored to this state later. y Observer Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. y State Allow an object to alter its behavior when its internal state changes. The object will appear to change its class. EMTM 600, Spring 2011 Val Tannen

Examples(6) From “Design patterns” by Gamma et al. , Addison. Wesley 1995 z Behavioral Examples(6) From “Design patterns” by Gamma et al. , Addison. Wesley 1995 z Behavioral Patterns (cont’d) y Strategy Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it. y Template Method Define the skeleton of an algorithm in an operation, deferring some steps to subclasses. Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm's structure. y Visitor Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates. EMTM 600, Spring 2011 Val Tannen

Example: Abstract Factory This is a creational pattern. We used this idea with the Example: Abstract Factory This is a creational pattern. We used this idea with the List. Spec interface for mutable lists. Context: Working with multiple standards. Problem: To provide an interface for creating families of related or dependent objects without specifying their concrete classes. Solution: Group creation methods in an abstract factory class (in Java probably an abstract class or an interface). Extend/implement this with concrete classes that follow each standard. Write generic code using the abstract factory methods to create needed objects. This code could also be in abstract classes, leaving abstract the use of the factory. Then specialize this code for a specific standard by implementing the factory with a concrete factory. EMTM 600, Spring 2011 Val Tannen

Example: Adapter This is a structural pattern. It is also called Wrapper (the Java Example: Adapter This is a structural pattern. It is also called Wrapper (the Java wrapper classes are adapters for the primitive types). We can use it, for example, to implement stacks, queues and even priority queues (as we did!) using ranked sequences. Context: Many! Problem: Classes that need to work together cannot because of incompatible interfaces. Therefore we need to convert the interface of a class into another interface clients expect. Solution: We can make the “adaptee” a subclass of the target (as we did with priority queues and ranked sequences) but some do not consider this good design. Instead they recommend that the adaptee have a private field refering to a target object (more like “wrapping”). EMTM 600, Spring 2011 Val Tannen

Example: Iterator This is a behavioral pattern. The Java Enumeration is an approximate example Example: Iterator This is a behavioral pattern. The Java Enumeration is an approximate example (the methods are a little different). Context: Working with collections of objects. Problem: Access the objects in a collection sequentially without exposing the underlying representation of the collection. Solution: We build the iterators as objects associated with the collections, having access to their representation. (In Java this suggest strongly using inner classes. ) The state of an iterator is given by a “cursor” referring to the current element of the collection. Iterators should have an advance method, a method to access the current element, a method to test if the whole collection was traversed, and a method to restart the traversal. Multiple iterators on the same collection are useful. Also useful is starting an iterator at some element referred to by another iterator. EMTM 600, Spring 2011 Val Tannen

Mutable Lists as an Abstract Factory public List } interface List. Spec { // Mutable Lists as an Abstract Factory public List } interface List. Spec { // Example of Abstract Factory. nil(); // Methods that create products. sng(Object o); // In general, the products are of list(Object[] ao); // various kinds (here all are lists). public interface List { // Interface for Abstract Product. void add. Head(Object o); boolean is. Empty(); Object head() throws Empty. List. Exception; void remove. Head() throws Empty. List. Exception; void append. Tail(List l); Iterator iter(); // See Iterator interface. } EMTM 600, Spring 2011 Val Tannen

Mutable lists implementation class LLImpl implements List. Spec { static class Cell { … Mutable lists implementation class LLImpl implements List. Spec { static class Cell { … } static class Linked. List implements List{ … // Iterator implementation in here. See next. } public List nil() { … } public List sng(Object o) { … } public List list(Object[] ao) { List rl = nil(); for (int i=ao. length-1; i>-1; i--) rl. add. Head(ao[i]); return rl; … EMTM 600, Spring 2011 Val Tannen

Iterator specification public interface Iterator { // Example of Iterator design pattern. boolean has. Iterator specification public interface Iterator { // Example of Iterator design pattern. boolean has. More(); // No insert void next(); // or delete methods. Object current(); void reset(); // Restart at beginning. Iterator spawn(); // Create new iterator, // initialize it at same current element. } EMTM 600, Spring 2011 Val Tannen

Iterator use public String to. String() { // Overriding method in Object. Iterator i Iterator use public String to. String() { // Overriding method in Object. Iterator i = iter(); String. Buffer sb = new String. Buffer(); sb. append("n[ "); while (i. has. More()) { sb. append(i. current() + " "); i. next(); This is unrelated, but } interesting! Inside sb. append("]"); class Linked. List. return sb. to. String(); } EMTM 600, Spring 2011 Val Tannen

Iterator implementation … // Inside the class Linked. List (which implements List). class Iter Iterator implementation … // Inside the class Linked. List (which implements List). class Iter implements Iterator { // Inner class. Instances tied to Cell cursor; // enclosing linked list instance. Iter () { cursor = first; } public boolean has. More() { return (cursor != null); } public void next() { cursor = cursor. next; } public Object current() { return cursor. content; } public void reset() { cursor = first; } public Iterator spawn() { Iter i = new Iter(); i. cursor = cursor; return i; }. . . public Iterator iter() { return new Iter(); } … // Class Linked. List continues. EMTM 600, Spring 2011 Val Tannen

Adapter implementation public class List. Stack implements Stack { // Example of Adapter design Adapter implementation public class List. Stack implements Stack { // Example of Adapter design pattern. private List the. List; // Here we “wrap” a list. public List. Stack(List. Spec I) { the. List = I. nil(); } We could have also used public void push(Object o) { inheritance. the. List. add. Head(o); } public void pop() throws Empty. Stack. Exception { try { the. List. remove. Head(); } catch (Empty. List. Exception e) { throw new Empty. Stack. Exception(); … EMTM 600, Spring 2011 Val Tannen

Anti. Patterns and Refactoring A reaction to the hype over design patterns. • Anti. Anti. Patterns and Refactoring A reaction to the hype over design patterns. • Anti. Patterns identify common mistakes in software development; mistakes in architectural design, detailed design/coding practice, and even process management (this not covered by design patterns!) • Anti. Patterns also provide refactoring solutions (fixing the mistakes!). • Refactoring should improve the design and hence • the reliability, • the maintainability, • in the longer term: the productivity EMTM 600, Spring 2011 Val Tannen

Aspects of an Anti. Pattern • Recall aspects of Design Patterns: Context, Problem, Solution Aspects of an Anti. Pattern • Recall aspects of Design Patterns: Context, Problem, Solution • Anti. Pattern aspects: • Context and Causes • Anti. Pattern (bad!) Solution • Symptoms and Consequences • Refactored Solution EMTM 600, Spring 2011 Val Tannen

Key Concepts for Anti. Patterns • Root Causes (a. k. a the seven software Key Concepts for Anti. Patterns • Root Causes (a. k. a the seven software development sins) haste; apathy; narrow-mindedness; sloth; avarice; ignorance; pride. • Primal Forces, eg. , • • • meeting the user requirements achieving reasonable performance defining abstractions/managing complexity managing change/controlling evolution managing IT resources managing the transfer of technology EMTM 600, Spring 2011 Val Tannen

Key Concepts, cont’d • Software Design (and Process) Levels • Global/Industry: standards, Internet • Key Concepts, cont’d • Software Design (and Process) Levels • Global/Industry: standards, Internet • Enterprise: infrastructures, policies, reference models (local standards) • System: interacting applications, metadata (schemas, ontologies) • Application: requirements, interfaces, GUIs • Macro-component/frameworks (optional): eg. , EJB, . NET, design patterns • Component: reusability, detailed design patterns • Objects&Classes: detailed functionality EMTM 600, Spring 2011 Val Tannen

From “Anti. Patterns” by Brown et al. , Wiley 1998 Examples z Management Anti. From “Anti. Patterns” by Brown et al. , Wiley 1998 Examples z Management Anti. Patterns y Analysis Paralysis Not knowing when to stop worrying about details… y Death by Planning Can’t get started until complete project plan… y Smoke and Mirrors (Vaporware): Demo system is used by sales to make impossible claims and promises. . . y Intellectual Violence You don’t know Lambda Calculus? !? y Viewgraph Engineering Making your Java programmers spend too much time on Powerpoint. . . y Blowhard Jamboree The expert said… But the guru may be misinformed or biased. . . EMTM 600, Spring 2011 Val Tannen

Example: Stovepipe Enterprise This is a software architecture antipattern. From “Anti. Patterns” by Brown Example: Stovepipe Enterprise This is a software architecture antipattern. From “Anti. Patterns” by Brown et al. , Wiley 1998 Context and causes: Multiple systems within an enterprise, designed independently; lack of standard reference model; lack of incentive for cooperation across development groups. Root causes: haste, apathy, narrow-mindedness. Unbalanced primal forces: change, IT resources, and technology transfer management. Antipattern solution: Ad-hoc enterprise-level architecture. Symptoms and Consequences: [Metal stovepipe constantly corroded by wood fumes, constantly patched with improvised materials. ] y Bad interoperability between systems: incompatible terminology and approaches. y Undocumented or incomprehensible architectures. y Incorrect use of a technology standard. y Excessive maintenance costs when requirements change. y Employee turnover. EMTM 600, Spring 2011 Val Tannen

Stovepipe Enterprise, cont’d Refactored Solution: Enterprise Architecture Planning z Coordination of technologies at several Stovepipe Enterprise, cont’d Refactored Solution: Enterprise Architecture Planning z Coordination of technologies at several levels y Ruless in the spirit of “building codes”and “zoning laws”. y Common infrastructure of basic services y Dept/division infrastructure of “value-added” functional services z For very large enterprises it is becomes worthwhile to add y Open systems reference models (one/enterprise) y Technology profile (one/enterprise ) y Operating environment (one/enterprise) y System requirements profile (one/system family) y Computing facilities architecture (one/system family) y Interoperability specifications (one/key interoperability point) y Development profile (one/system family) EMTM 600, Spring 2011 Val Tannen

Example: The Blob From “Anti. Patterns” by Brown et al. , Wiley 1998 This Example: The Blob From “Anti. Patterns” by Brown et al. , Wiley 1998 This is a detailed design antipattern. Context and causes: Many contexts, especially with inexperienced programmers, or when non-OO legacy design is migrated into OO. Root causes: sloth, haste, ignorance. Unbalanced primal forces: meeting user requirements, achieving performance, managing complexity and abstraction. Antipattern solution: One part of a component (typically a single class) monopolizes the processing while the rest just encapsulates data. Symptoms and Consequences: y Single class with too many attributes and/or operations. y Unrelated attributes and/or operations in the same class. y Operations with too many parameters and lost of code, typically involving many condition tests. y This is against the spirit of OO design and coding. y Blob classes are too complex for reuse. y Blob classes are too complex for reliable testing! EMTM 600, Spring 2011 Val Tannen

The Blob, cont’d Refactored Solution: Refactoring of UML diagrams and code to move behavior The Blob, cont’d Refactored Solution: Refactoring of UML diagrams and code to move behavior away from the blob. z Identify attributes and operations that are related according to functionalities in a more abstract view, or in use cases. z Look for “natural homes” for groups of related attributes and operations. Create new classes if necessary. z Identify unrelated functionality in the behavior of each operation. “Break-up” operations by creating auxilliary one in their natural homes. z Eliminate “transient” object or variables (temporary variables), especially if they communicate data within a large operation. EMTM 600, Spring 2011 Val Tannen

Example: Poltergeists From “Anti. Patterns” by Brown et al. , Wiley 1998 This is Example: Poltergeists From “Anti. Patterns” by Brown et al. , Wiley 1998 This is a detailed design antipattern. Context and causes: Many contexts, especially with large group efforts, also when architects do not understand object-orientation. Root causes: sloth, ignorance, pride. Unbalanced primal forces: meeting user requirements, managing complexity and abstraction. Antipattern solution: Components or classes with limited responsibilities, are made visible outside of their useful scope and beyond their useful life. Symptoms and Consequences: y Cluttered design. y Poltergeists are hard to understand out of their useful context, leads to mistaken use, difficulties in maintenance. y Stateless classes, used just for control. y Single-operation classes. Refactored Solution: Remove them! Replace the functionality they provided by modifiying/adding appropriate operations. EMTM 600, Spring 2011 Val Tannen