DOCSLIB.ORG

RMA: a Pattern Based J2EE Development Tool

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
RMA: a Pattern Based J2EE Development Tool RMA: A Pattern Based J2EE Development Tool by Jun Chen A thesis presented to the University of Waterloo in ful¯lment of the thesis requirement for the degree of Master of Mathematics in Computer Science Waterloo, Ontario, Canada, 2004 °c Jun Chen 2004 AUTHOR'S DECLARATION FOR ELECTRONIC SUBMISSION OF A THESIS I hereby declare that I am the sole author of this thesis. This is a true copy of the thesis, including any required ¯nal revisions, as accepted by my examiners. I understand that my thesis may be made electronically available to the public. ii Abstract The development process for creating J2EE web applications is complex and tedious, and is thus error prone. The quality of a J2EE web application depends on correctness of code as well as the e±ciency and flexibility of its architecture. Although the J2EE speci¯cation has promised to hide the distributed nature of the application, application developers still have to be aware of this fact in both the design (architecture) and implementation (code) perspectives. In this thesis, we present the detailed design of our pattern-based J2EE development tool, RoadMapAssembler (RMA). RMA demonstrates how patterns can be used to generate e±cient architectural code while also hiding the deployment logic and distributed nature of J2EE applications in the implementation perspective. Furthermore, it shows the generation of a J2EE framework as a process of assembling patterns in an incremental fashion using known inter-pattern relationships. iii Acknowledgement I would like to express my deepest gratitude to my supervisor, Professor Steve MacDonald. His guidance, insight and expressive clarity have served as an inspiration and have helped me tremen- dously during these past two years. This thesis would not be possible without his patience and advice. I would also like to thank my readers, Professor Tim Brecht and Professor Richard Trefler for taking the time to review my thesis. Also, I like to thank my friends who had helped me so much in the past two years. A special thank you to my parents for their endless love, support and encouragement during my studies away from home. iv Contents 1 Introduction 1 1.1 Introduction . 1 1.1.1 The Development Process . 1 1.1.2 The Deployment Process . 3 1.2 Contribution . 3 1.2.1 RoadMapAssembler . 4 1.3 Outline . 4 2 Background 7 2.1 J2EE . 7 2.1.1 Presentation Tier Technologies . 8 2.1.2 EJBs . 9 2.1.3 Data Access Technologies . 10 2.1.4 Deployment Tools . 11 2.2 Eclipse . 13 3 J2EE Framework and Patterns 16 3.1 Data Access Object . 18 3.2 Transfer Value Object . 20 3.3 Session Fa»cade . 21 3.4 Service Locator . 23 3.5 Transfer Object Assembler . 25 3.6 Value List Handler . 27 v 3.7 Business Delegate . 28 3.8 Summary . 29 4 Pattern Relationships And Pattern Assembly 31 4.1 Pattern Relationships . 31 4.1.1 Transfer Value Object + Data Access Object . 33 4.1.2 Transfer Object Assembler + Data Access Object Subcomponent . 34 4.1.3 Value List Handler + Data Access Object Subcomponent . 37 4.1.4 Session Fa»cade+ Business Components . 39 4.1.5 Service Locator + Business Delegate + Session Fa»cadeSubcomponent . 42 4.1.6 Discussion on Pattern Relationships . 44 4.2 Pattern Assembly . 45 4.2.1 Assembly Processes . 46 4.2.2 Writing Application Code . 58 4.3 A Sample Application . 60 4.3.1 Assembling a Sample Application . 62 4.3.2 Discussion . 68 4.4 Summary . 68 5 Isolation of Deployment Logic 70 5.1 Removing Deployment Logic at the Code Level . 72 5.1.1 Generating Access Interfaces . 72 5.1.2 Re¯ned Service Locator . 74 5.1.3 Proxy for EJBs . 78 5.1.4 Discussion . 79 5.2 Generating Deployment Files . 81 5.2.1 Generating Deployment Descriptor Files . 82 5.2.2 Packaging the EAR File . 83 5.3 Summary . 84 6 Analysis 85 vi 7 Related Work 89 7.1 COPS for Parallel Programming . 89 7.2 Tools for J2EE Development . 90 7.2.1 JBuilder and WebSphere . 91 7.2.2 Struts . 92 7.2.3 Pattern Transformation based JAFAR . 92 7.2.4 Model Transformation based OptimalJ . 94 7.2.5 Role/Constraint based Fred . 97 7.3 Summary . 99 8 Future Work and Conclusion 100 8.1 Future Work . 100 8.2 Conclusion . 101 A Acronyms 106 B UML Legends 108 vii List of Figures 1.1 RMA Architecture . 5 2.1 J2EE Container Architecture . 8 2.2 Hierarchy of a J2EE Application Archive . 12 3.1 Sun's J2EE framework . 17 3.2 Data Access Object . 19 3.3 Transfer Value Object Class Diagram . 21 3.4 Session Fa»cadeClass Diagram . 23 3.5 Service Locator . 24 3.6 Transfer Object Assembler . 26 3.7 Value List Handler . 28 3.8 Business Delegate . 29 4.1 Transfer Value Object and Data Access Object . 35 4.2 Transfer Value Object, Transfer Object Assembler and Data Access Object . 37 4.3 Transfer Value Object, Data Access Object and Value List Handler . 38 4.4 Session Fa»cadeand EJBs . 41 4.5 Service Locator + Business Delegate . 43 4.6 Sample Code for the Transfer Value Object . 48 4.7 Sample Code for the Data Access Object-1 . 49 4.8 Sample Code for the Data Access Object-2 . 50 4.9 Sample Code for the Assembler . 53 4.10 Sample Code for the Value List Handler . 55 viii 4.11 Sample Code for the Session Fa»cade . 57 4.12 Sample Code for the Business Delegate . 59 4.13 Use Cases for Sample Application . 60 4.14 Simpli¯ed Architecture for Sample Application . 61 4.15 Wizard Pages for Generating DAO . 63 4.16 Wizard Pages for Generating the Transfer Object Assembler . 64 4.17 Wizard Pages for Generating Session Facade . 66 4.18 Wizard Page for Generating Value List Handler . 67 5.1 Code for Accessing an EJB . 71 5.2 Code for Re¯ned Service Locator-1 . 76 5.3 Code for Re¯ned Service Locator-2 . 77 5.4 Class Diagram for EJB Proxy . 78 5.5 Layers for Generated Code of Hiding Distributed Computing . 80 B.1 UML Legend-Class Symbols . 108 B.2 UML Legends-Association Symbols . 109 ix List of Tables 4.1 The Categorization of Roles in the Relationships . 45 6.1 Code Distribution on Generated Code for Architecture . ..
Load more

Recommended publications
  • Design Pattern Interview Questions
    DDEESSIIGGNN PPAATTTTEERRNN -- IINNTTEERRVVIIEEWW QQUUEESSTTIIOONNSS http://www.tutorialspoint.com/design_pattern/design_pattern_interview_questions.htm Copyright © tutorialspoint.com Dear readers, these Design Pattern Interview Questions have been designed specially to get you acquainted with the nature of questions you may encounter during your interview for the subject of Design Pattern. As per my experience good interviewers hardly plan to ask any particular question during your interview, normally questions start with some basic concept of the subject and later they continue based on further discussion and what you answer: What are Design Patterns? Design patterns represent the best practices used by experienced object-oriented software developers. Design patterns are solutions to general problems that software developers faced during software development. These solutions were obtained by trial and error by numerous software developers over quite a substantial period of time. What is Gang of Four GOF? In 1994, four authors Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides published a book titled Design Patterns - Elements of Reusable Object-Oriented Software which initiated the concept of Design Pattern in Software development. These authors are collectively known as Gang of Four GOF. Name types of Design Patterns? Design patterns can be classified in three categories: Creational, Structural and Behavioral patterns. Creational Patterns - These design patterns provide a way to create objects while hiding the creation logic, rather than instantiating objects directly using new opreator. This gives program more flexibility in deciding which objects need to be created for a given use case. Structural Patterns - These design patterns concern class and object composition. Concept of inheritance is used to compose interfaces and define ways to compose objects to obtain new functionalities.
    [Show full text]
  • A Design Pattern Approach
    Wright State University CORE Scholar Browse all Theses and Dissertations Theses and Dissertations 2009 Automated Transforms of Software Models: A Design Pattern Approach Brandon Adam Gump Wright State University Follow this and additional works at: https://corescholar.libraries.wright.edu/etd_all Part of the Computer Sciences Commons Repository Citation Gump, Brandon Adam, "Automated Transforms of Software Models: A Design Pattern Approach" (2009). Browse all Theses and Dissertations. 969. https://corescholar.libraries.wright.edu/etd_all/969 This Thesis is brought to you for free and open access by the Theses and Dissertations at CORE Scholar. It has been accepted for inclusion in Browse all Theses and Dissertations by an authorized administrator of CORE Scholar. For more information, please contact [email protected]. AUTOMATED TRANSFORMS OF SOFTWARE MODELS: A DESIGN PATTERN APPROACH A thesis submitted in partial fulfillment of the requirements for the degree of Master of Science By BRANDON ADAM GUMP B.S., Wright State University, 2008 2009 Wright State University WRIGHT STATE UNIVERSITY SCHOOL OF GRADUATE STUDIES November 23, 2009 I HEREBY RECOMMEND THAT THE THESIS PREPARED UNDER MY SUPERVISION BY Brandon Adam Gump ENTITLED Automated Transforms of Software Models: A Design Pattern Approach BE ACCEPTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF Master of Science . Thomas C. Hartrum, Ph.D. Thesis Co-Director Mateen M. Rizki, Ph.D. Thesis Co-Director Thomas A. Sudkamp, Ph.D. Department Chair Committee on Final Examination Thomas C. Hartrum, Ph.D. Mateen M. Rizki, Ph.D. Travis E. Doom, Ph.D. Joseph F. Thomas, Jr., Ph.D. Dean, School of Graduate Studies ABSTRACT Gump, Brandon Adam.
    [Show full text]
  • Design Optimizations of Enterprise Applications – a Literature Survey
    Design Optimizations of Enterprise Applications – A Literature Survey Willie (Phong) Tu Dept. of Computer Science, University of Calgary [email protected] Abstract Another dimension is the performance improvement for the single user versus multiple users, in other words, Software design patterns have been defined as scalability. The design optimization patterns noted here possible solutions to reoccurring problems. One aspect will focus on actual running time of operations for of the problems is performance. This can be arguably single user performance and multi-user scalability true in high volume enterprise applications. This paper improvements. will explore the current discussions and research in The organization of the findings is categorized utilization of software design patterns to optimize through the usage of an architectural pattern, which is enterprise applications. defined as layer [5]. The layers used are the primary three-layer architecture for information systems [10,21], which includes the data access layer, domain layer, and 1. Introduction presentation layer. Design optimization patterns that spans layers will be elaborated first, then a bottom up First, let’s define what is design optimization. In this approach starting with the data access layer, followed by context, design optimization is the improvement of an the domain layer, and finally the presentation layer. We application’s design and performance using software will then continue on with findings from different design patterns. Design improvements can be subjective, enterprise applications. After which, we will summarize thus the main qualifier is the utilization of software the current state in design optimizations of enterprise design patterns to improve the performance of an applications based on the findings.
    [Show full text]
  • Sun Certified Enterprise Architect for Java EE Study Guide / Mark Cade, Humphrey Sheil
    Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and the publisher was aware of a trademark claim, the designations have been printed with initial capital letters or in all capitals. Sun Microsystems, Inc. has intellectual property rights relating to implementations of the technology described in this publication. In particular, and without limitation, these intellectual property rights may include one or more U.S. patents, foreign patents, or pending applications. Sun, Sun Microsystems, the Sun logo, J2ME, J2EE, Java Card, and all Sun and Java based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc., in the United States and other countries. UNIX is a registered trademark in the United States and other countries, exclusively licensed through X/Open Company, Ltd. This publication is provided “as is” without warranty of any kind, either express or implied, including, but not limited to, the implied warranties of merchantability, fitness for a particular purpose, or non-infringement. This publication could include technical inaccuracies or typographical errors. Changes are periodically added to the information herein; these changes will be incorporated in new editions of the publication. Sun Microsystems, Inc. may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time. The authors and publisher have taken care in the preparation of this book, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein.
    [Show full text]
  • Design Pattern Driven Development of Model Transformations
    DESIGN PATTERN DRIVEN DEVELOPMENT OF MODEL TRANSFORMATIONS by HUSEYIN ERGIN JEFF GRAY, COMMITTEE CHAIR JEFFREY CARVER RALF LAEMMEL RANDY SMITH EUGENE SYRIANI SUSAN VRBSKY A DISSERTATION Submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy in the Department of Computer Science in the Graduate School of The University of Alabama TUSCALOOSA, ALABAMA 2017 Copyright Huseyin Ergin 2017 ALL RIGHTS RESERVED ABSTRACT Model-Driven Engineering (MDE) is considered a well-established software development ap- proach that uses abstraction to bridge the gap between the problem space and the software implementation. These abstractions are represented by models that make the validation of the real system easier. In MDE, many problems are solved using model transformation, which is a paradigm that manipulates high-level models to translate, evolve, or simulate them. However, the development of a model transformation for a specific problem is still a hard task. The main reason is the lack of a development process where transformations must be designed before implemented. Design patterns provide experiential reuse to soft- ware engineers when faced with recurring problems. In the literature, design patterns have been used to generate partially reusable software designs in order to help developers. There are many design patterns focused development methodologies proposed. However, most of them specialize in object-oriented design patterns. Given the various contexts in which de- sign patterns have been applied, model transformations may also benefit from a patterns approach. Although several studies have proposed design patterns for model transforma- tion, there is still no accepted common language to express them or a methodology that places design patterns at the heart of the development of model transformations.
    [Show full text]
  • [ Team Lib ] Crawford and Kaplan's J2EE Design Patterns Approaches
    [ Team LiB ] • Table of Contents • Index • Reviews • Reader Reviews • Errata J2EE Design Patterns By William Crawford, Jonathan Kaplan Publisher: O'Reilly Pub Date: September 2003 ISBN: 0-596-00427-3 Pages: 368 Crawford and Kaplan's J2EE Design Patterns approaches the subject in a unique, highly practical and pragmatic way. Rather than simply present another catalog of design patterns, the authors broaden the scope by discussing ways to choose design patterns when building an enterprise application from scratch, looking closely at the real world tradeoffs that Java developers must weigh when architecting their applications. Then they go on to show how to apply the patterns when writing realworld software. They also extend design patterns into areas not covered in other books, presenting original patterns for data modeling, transaction / process modeling, and interoperability. [ Team LiB ] [ Team LiB ] • Table of Contents • Index • Reviews • Reader Reviews • Errata J2EE Design Patterns By William Crawford, Jonathan Kaplan Publisher: O'Reilly Pub Date: September 2003 ISBN: 0-596-00427-3 Pages: 368 Copyright Preface Audience Organization of This Book For Further Reading Conventions Used in This Book Comments and Questions Acknowledgments Chapter 1. Java Enterprise Design Section 1.1. Design Patterns Section 1.2. J2EE Section 1.3. Application Tiers Section 1.4. Core Development Concepts Section 1.5. Looking Ahead Chapter 2. The Unified Modeling Language Section 2.1. Origins of UML Section 2.2. The Magnificent Seven Section 2.3. UML and Software Development Lifecycles Section 2.4. Use Case Diagrams Section 2.5. Class Diagrams Section 2.6. Interaction Diagrams Section 2.7.
    [Show full text]
  • IC Coder's Club Design Patterns (In C++)
    Andrew W. Rose Simple exercise You have been tasked to move this pile from A to B Simple exercise You have been tasked to move this pile from A to B You have three resources available to you: a) Bare hands b) A stack of timber c) A horse and cart Simple exercise You have been tasked to move this pile from A to B You have three resources available to you: a) Bare hands b) A stack of timber c) A horse and cart How do you achieve the task in the quickest, least-painful way, which won’t leave you up-to-your-neck in the produce you are moving, nor smelling of it? Software analogy a) Bare hands b) A stack of timber c) A horse and cart Software analogy a) Bare hands b) A stack of timber c) A horse and cart Do a task manually Software analogy a) Bare hands b) A stack of timber c) A horse and cart Design Do a task the tools manually yourself Software analogy a) Bare hands b) A stack of timber c) A horse and cart Benefit from Design Do a task someone the tools manually else’s yourself hard work Software analogy a) Bare hands b) A stack of timber c) A horse and cart Benefit from someone else’s This is the purpose of design patterns! hard work Motivation I will, in fact, claim that the difference between a bad programmer and a good one is whether he considers his code or his data structures more important: Bad programmers worry about the code; good programmers worry about data structures and their relationships.
    [Show full text]
  • FC++: Functional Tools for Object-Oriented Tasks
    FC++: Functional Tools for Object-Oriented Tasks Yannis Smaragdakis and Brian McNamara College of Computing Georgia Institute of Technology Atlanta, GA 30332 {yannis,lorgon}@cc.gatech.edu http://www.cc.gatech.edu/~yannis/fc++ Abstract straightforwardly many common functional opera- tors (a large part of the Haskell Standard Prelude FC++ is a library for programming functionally in [19]). The library is currently quite rich in func- C++. Compared to other C++ functional program- tionality and has an efficient implementation. ming libraries, FC++ is distinguished by its power- ful type system which allows manipulating In a previous paper [16], we introduced FC++ and parametrically polymorphic functions (e.g., pass- its innovative type system, showed the components ing them as arguments to other functions and of the library, and demonstrated how its implemen- returning them as results). tation is more efficient than previous similar attempts. In this paper we show how to leverage In this paper, we show how FC++ can be used in the library to create simple, efficient, and safe common OO programming tasks. We demonstrate implementations of common OO design patterns FC++ implementations of several common design [8]. patterns (Adapter, Builder, Command, and more). Compared to conventional C++ implementations Certainly a lot has been written about language of these patterns, our implementations are either support for implementing design patterns (e.g., simpler (in that fewer classes/dependencies are [4][6]), functional techniques in OO programming, needed), more efficient, or more type-safe (thanks etc. Some of the approaches in the literature are to parametric polymorphism and type-inference). even very close in philosophy to our work.
    [Show full text]
  • Software Frameworks, Architectural and Design Patterns
    Journal of Software Engineering and Applications, 2014, 7, 670-678 Published Online July 2014 in SciRes. http://www.scirp.org/journal/jsea http://dx.doi.org/10.4236/jsea.2014.78061 Software Frameworks, Architectural and Design Patterns Njeru Mwendi Edwin Department of Computing, Jomo Kenyatta University of Agricluture & Technology, Nairobi, Kenya Email: [email protected] Received 21 April 2014; revised 20 May 2014; accepted 14 June 2014 Copyright © 2014 by author and Scientific Research Publishing Inc. This work is licensed under the Creative Commons Attribution International License (CC BY). http://creativecommons.org/licenses/by/4.0/ Abstract Software systems can be among the most complex constructions in engineering disciplines and can span into years of development. Most software systems though implement in part what has already been built and tend to follow known or nearly known architectures. Although most soft- ware systems are not of the size of say Microsoft Windows 8, complexity of software development can be quick to increase. Thus among these methods that are the most important is the use of ar- chitectural and design patterns and software frameworks. Patterns provide known solutions to re-occurring problems that developers are facing. By using well-known patterns reusable compo- nents can be built in frameworks. Software frameworks provide developers with powerful tools to develop more flexible and less error-prone applications in a more effective way. Software frame- works often help expedite the development process by providing necessary functionality “out of the box”. Providing frameworks for reusability and separation of concerns is key to software de- velopment today.
    [Show full text]
  • Security Analysis of Core J2EE Patterns Project
    Security Analysis of Core J2EE Patterns Project INTRODUCTION Most application security experts focus on a single activity for integrating design into the SDLC: threat modeling . Threat modeling is excellent at approximating an application’s attack surface but, in our experience, developers sometimes do not have the time, budget or security know-how to build an adequate threat model. Perhaps more importantly, developers cannot create a comprehensive threat model until they complete the application design. This reference guide aims at dispensing security best practices to developers to make security decisions during design. We focus on one of the most important concepts in modern software engineering: design patterns. Ever since the publication of the seminal Design Patterns Book , developers have reused common patterns such as Singleton and Factory Method in large-scale software projects. Design patterns offer a common vocabulary to discuss application design independent of implementation details. One of the most critically acclaimed pattern collections in the Java Enterprise Edition (JEE) community is the Core J2EE Patterns book by Deepak Alur, Dan Malks and John Crupi . Developers regularly implement patterns such as “Application Controller”, “Data Access Object” or “Session Façade” in large, distributed JEE applications and in frameworks such as Spring and Apache Struts . We aim to dispense security best practices so that developers can introduce security features and avoid vulnerabilities independent of their underlying technology choices such as which Model View Controller (MVC) framework to use. Java developers currently have access to patterns for security code (e.g. how to develop authentication, how to implement cryptography) such as the Core Security Patterns book.
    [Show full text]
  • Java EE Patterns
    iiinsielinsiel Informatica per il Sistema degli Enti Locali SpA via san Francesco, 43 34133 Trieste tel +39 040 3737111 fax +39 040 3737333 www.insiel.it [email protected] SL-500-EE5 ––– Java EE Patterns obiettivi Upon completion of this course, students should be able to: Select an appropriate Gang of Four or Java EE pattern to solve a specific problem. Apply a Gang of Four or Java EE pattern to an architecture and implementation. Design and implement more effective Java EE applications. prerequisiti To succeed fully in this course, students must be able to: Develop enterprise Java applications Read and work with Object-Oriented modeling techniques, such as the Unified Markup Language (UML) Explain the use of technologies within the Java EE platform Work with the following Java technologies: Enterprise JavaBeans, JavaServer Pages, and servlets Related courses Related courses before OO-226: Object-Oriented Analysis and Design Using UML (OO-226) SL-425: Developing Architectures for Enterprise Java Applications (SL-425) a chi è rivolto Programmatori Java durata 4 gg. programma Exploring Object-Oriented Design Principles and Design Describe the basic characteristics of the Structural Patterns patterns Describe the fundamental object-oriented design Apply the Facade pattern concepts Apply the Proxy pattern Describe the fundamental object-oriented design Apply the Adapter pattern principles Apply the Composite pattern Describe the characteristics of design patterns Apply the Decorator pattern Using Gang of Four Behavioral Patterns Using Architectural
    [Show full text]
  • Amity School of Engineering & Technology Amity
    Amity School of Engineering & Technology Amity University Object Oriented System Design Code: CSE416 Prepared By Hari Mohan Pandey Assistant Professor, CSE Department [email protected] Module Notes Department of Computer Science & Engineering ODD Semester 2014 Object Oriented System Design Page: 1/74 UNIT-3 DIAGRAMS 3.1 Sequence diagrams A sequence diagram is an interaction diagram that details how operations are carried out - - what messages are sent and when. Sequence diagrams are organized according to time. The time progresses as you go down the page. The objects involved in the operation are listed from left to right according to when they take part in the message sequence. Below is a sequence diagram for making a hotel reservation. The object initiating the sequence of messages is a Reservation window. Figure: Sequence Diagram-1 Object Oriented System Design Page: 2/74 The Reservation window sends a makeReservation () message to a HotelChain. The HotelChain then sends a makeReservation () message to a Hotel. If the Hotel has available rooms, then it makes a Reservation and a Confirmation. Within a sequence diagram, on object is available in the box at the top of a dotted vertical line. Each vertical dotted line is a lifeline, representing the time that an object exists. Each arrow is a message call. An arrow goes from the sender to the top of the activation bar of the message on the receiver's lifeline. The activation bar represents the duration of execution of the message. Each message is labeled at minimum with the message name. In our diagram, the Hotel issues a self call to determine if a room is available.
    [Show full text]