DOCSLIB.ORG

Information Systems Modelling – UML and Service Description Languages

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Information Systems Modelling – UML and Service Description Languages InternetInternet EngineeringEngineering TomaszTomasz BabczyBabczy ńński,ski, ZofiaZofia KruczkiewiczKruczkiewicz TomaszTomasz KubikKubik InformationInformation systemssystems modellingmodelling –– UMLUML andand serviceservice descriptiondescription languageslanguages Design patterns used to build the Business Tier D.Alur, J.Crupi, D. Malks, Core J2EE. Desin Patterns 1. A definition of the Business Tier – a five-tiered model of logical separation of tasks 2. Basic Business Tier design issues 3. Bad practices when designing the Business Tier 4. Analysis of basic design issues Design patterns used to build the Business Tier D.Alur, J.Crupi, D. Malks, Core J2EE. Desin Patterns 1. The definition of the Business Tier – a five- tiered model of logical separation of tasks Multitiered Information System by D.Alur, J.Crupi, D. Malks, Core J2EE. Desin Patterns Client Tier Interacting with the user, device and user interface Customer applications, applets, elements of presentation the graphical user interface Presentation Tier Login, session management, content creation and delivery, JSP Pages, servlets, and other user form atting and validation interface elements Business Tier Business logic, transactions, EJB components and other business data and services objects Integration Tier Resource adapters, external systems, mechanisms for JMS, JDBC, connectors and connections resource, control flow with external systems Resource Tier Resources, data and external Databases, external systems and other services resources Business Tier (Tutorial Java EE 5) Application Client Web Browser, And Optional Web Pages, JavaBeans Applets, and Client Tier Components Optional JavaBeans Components JavaBeens Web Pages Components Servlets Web Tier (Optional) Java EE Java Persistence Entities Business Tier Server Session Beans Message-Driven Beans Database and EIS Tier Legacy Systems Design patterns used to build the Business Tier D.Alur, J.Crupi, D. Malks, Core J2EE. Desin Patterns 1. The definition of the Business Tier – a five- tiered model of logical separation of tasks 2. Basic Business Tier design issues Basic issues of Business Tier design 1. Using session components 2. Use of Entity components 3. Caching references and handles to remote enterprise bean components Using session components (1) The session component (EJB specification) is characterized as follows: • It is used by one customer or user • There is only for the duration of the session • It is destroyed during the failure of container • It is not a permanent object • There is a time limit of its life • It may participate in transactions • It can be used to modelling communication such as stateful or stateless between the Client and Business Tier components Using session components (2) – Component stateless session: • Do not store customer session data • Can be allocated any instance of the stateless session component for each customer from a pool of stateless session components • They are used in case of a service that requires only one method call – Component stateful session: • Stores session state • Components are returned into a pool of session stateful component only when the client has completed its session • If the service requires a number of method calls to complete the transaction, which is a conversational process. This choice improves the scalability of the system Using session components (3) • Storing session state: – Web Applications store the session state of clients in the Presentation Tier – Applications, with different types of clients, are keeping the session state in the Business Tier • Managing session state is dependent on: – Hardware – Network Traffic Management – The use of clustering for Web container – The use of clusters for the EJB container – Linking client session to a particular server in the cluster – Session Replication – Session Persistence Using Entity components – EJB specification (1) • Entity components are distributed, shared and persistent transactional objects, which work inside EJB containers • Entity components are used as the data of some business services • EJB containers provide additional infrastructure to support scalability, security, performance, clustering • Specification of Entity components (EJB specification): – They represent an object-oriented view of life – They participate in transactions – They are shared by multiple users – They have a long life – They are resistant to a failure of the container. This type of system crashes are usually invisible to customers Using Entity components – EJB specification (2) The Entity component must contain the business logic associated with the providing of services, which is self-sufficient in terms of handling their own data and data objects belonging to the dependent objects (POJO objects) . Keys in Entity components (for databases services): • A complex primary key requires a definition of class that implements the Serializable interface. Attributes of this class are the key attributes of the main complex key • The primary key class must redefine the hashCode and equals methods • If the primary key consists of a single attribute, then you can use the built-in type of the key Design patterns used to build the Business Tier D.Alur, J.Crupi, D. Malks, Core J2EE. Desin Patterns 1. The definition of the Business Tier – a five- tiered model of logical separation of tasks 2. Basic Business Tier design issues 3. Bad practices when designing the Business Tier Bad practices (1) • Mapping an object model directly on the model of Entity components – Impact: • Large container load • Generating high traffic – Solution: • Reducing the number of components - an application of the Composite Entity pattern • Creating a tier of access to services - the use of the Session Facade pattern Bad practices (2) • Mapping the relational model directly on the model of Entity components – Impact: • Large number of Entity components • Complex relalationships between Entity components – Solution: • Reducing the number of components - an application of the Composite Entity pattern • Moving the business logic to the Seession components - the use of the Session Facade pattern Bad practices (3) • Mapping each use case at a one session component – Effects • A large number of session components - high complexity applications – Solution • Session Facade pattern • Sharing all the attributes of components by the method of setting and collecting: set and get – Impact: • Large network traffic – Solution: • Transfer Object pattern Bad practices (4) • The client stores data of business components – Impact: • Large network traffic • Dependence on the model of client applications • Difficulties in modifying the software – Solution: • Transfer Object Assembler pattern • Embedding search services on the client side – Impact: • Visualization of the complexity of an application to the client • Redundant code - in case of changes to modify the code in many places in the application – Solution: • Business Delegate pattern • Locator Service pattern Other bad practices (5) • The use of components of the Entity as read-only objects • Using the Entity objects as a minor component • Saving an entire graph of related Entity components • Disclosure of the exceptions relating to EJB to customers outside the EJB Tier • Stateless session component restores session state for each call • Searching data using the methods, that return references to remote objects Design patterns used to build the Business Tier D.Alur, J.Crupi, D. Malks, Core J2EE. Desin Patterns 1. The definition of the Business Tier – a five- tiered model of logical separation of tasks 2. Basic Business Tier design issues 3. Bad practices when designing the Business Tier 4. Analysis of basic design issues Design cases 1. Conceal from the client program the complexity of remote communication with business service component 2. Transparent and uniform way to search services and business components 3. Sharing components and business services to remote clients (take control of the business objects and reducing network traffic, or improve efficiency) 4. Centralization of some business logic components and business services 5. The object model is an implementation of the conceptual model, which is the domain model, containing relationships and business logic 6. Use of Entity components to implement the conceptual domain model 7. Transferring data between tiers of application (reducing network traffic by reducing the number of remote calls, or improve efficiency) 8. Making lists of objects for remote clients applications Problem 1 – Conceal from the client program the complexity of remote communication with business service component Servlets and JSP with Session Logic of Data presentation logic Acc es Component with and: many searches business logic of and calls of business s ervices services, error services of other layers ect C lien t Se ssion Code of S er vlets, Co m po n en t Data Access D atabase JS P Client Tie r Presentation Inte gration R eso ur ce B u sine ss Tier Tie r Tie r T ier Servlets and JSP presentation Session Logic of Data logic and Business Delegate for Component with Ac ces separating layers but searches o f business logic of business services services C lient C ode of Data Se rvlets , B u sin ess Session Datab ase Acce ss Component JS P Deleg ate 1 Client T ier Presentation Integ ration B u sin ess R esourc e Tier Tier Tier T ier Refactorization by using Business Delegate component Session Entity Business Session Entity Component Component Delegate 1 Component Component 1 1
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]
  • 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.
    [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]