Ajs 2 c


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Ajs 2 c

  1. 1. CollaborateKnowledge Byte In this section, you will learn about: • Selecting a design pattern depending on the business requirements. • The various design patterns that form a part of the TheServerSide.com catalog. ©NIIT Collaborate Lesson 1C / Slide 1 of 24
  2. 2. CollaborateSelecting a Design Pattern • Design patterns enable you to design robust software by identifying the key steps undertaken during the application design phase, such as: • Identifying components and their internal structure and relationship among various components that constitutes a distributed application. • Determining and analyzing the level of communication among the components. • Defining the architecture of the presentation layer that is robust • The guidelines for selecting a design pattern are. • You need to identify the need for each type of design pattern. Once the purpose of each group of pattern is identified, choose the appropriate design pattern that helps to solve your problem. • You need to identify the type of problem that a design pattern solves and helps in narrowing the list of suitable design patterns that are applied to the given problem. ©NIIT Collaborate Lesson 1C / Slide 2 of 24
  3. 3. CollaborateSelecting a Design Pattern(Contd.) • You need to understand the problem and the related solution of each pattern, which enables you to select appropriate patterns. Based on the solution of each patterns, a final choice can be made to select a final design pattern. • You need to analyze and understand interrelations among patterns. The relevant patterns are grouped together to analyze the complete design and flow of applications. ©NIIT Collaborate Lesson 1C / Slide 3 of 24
  4. 4. CollaborateThe TheServerSide.com Patterns • The TheServerSide.com is an independent online Java community for enterprise developers and architects. • The TheServerSide community includes TheServerSide.NET, TheServerSide.com, and TheServerSide Symposiums. • TheServerSide.NET community focuses on enterprise development using Microsoft .NET framework. • TheServerSide Symposium discusses development issues that are related to an enterprise development environment. • TheServerSide.com organizes design patterns in different catalogs based on their functionality. ©NIIT Collaborate Lesson 1C / Slide 4 of 24
  5. 5. CollaborateThe TheServerSide.com Patterns(Contd.) • The TheServerSide.com patterns catalog includes: • EJB Layer architectural Patterns • Inter-tier data-Transfer Patterns • Transaction and Persistence Patterns • Client-side EJB Interaction Patterns • The EJB layer architectural category patterns include: • Session Facade: Provides an abstraction layer hiding all the underlying communication complexities in an EJB application. The use of session façade in an EJB application reduces remote method overhead by providing business components to act as interfaces to the clients. • Message Façade: Uses message-driven beans instead of session beans to enable asynchronous and fault-tolerant access. ©NIIT Collaborate Lesson 1C / Slide 5 of 24
  6. 6. CollaborateThe TheServerSide.com Patterns(Contd.) • EJB Command: Encapsulates the business logic in command beans and implements loose-coupling between the client and the business-logic tier. This loose coupling results in reducing the number of remote invocations. • Data Transfer Object Factory: Enables transferring of data objects by providing a factory. • Generic Attribute Access: Provides the technique to dynamically set and retrieve attributes of an entity bean using HashMaps. • Business Interface: Enables consistency checking of EJB interfaces during compile time. This pattern provides business interface to enable consistency checking, which needs to be implemented by both the local/remote interface and by the enterprise bean class. ©NIIT Collaborate Lesson 1C / Slide 6 of 24
  7. 7. CollaborateThe TheServerSide.com Patterns(Contd.) • The inter-tier data-transfer category patterns include: • Data-Transfer Object: Enables bulk transfer of data using serializable objects. • Domain Data-Transfer Object: Is an extension of Data-Transfer Object that enables transfer of data for a specific domain. • Custom Data-Transfer Object: Provides guidelines to transfer data as per the client requirements. • Data-Transfer HashMap: Enables grouping of arbitrary data between client and EJB tier using HashMaps. • Data-Transfer RowSet: Enables the use of RowSets to transfer relational data from ResultSet in the EJB tier to the client tier. ©NIIT Collaborate Lesson 1C / Slide 7 of 24
  8. 8. CollaborateThe TheServerSide.com Patterns(Contd.) • The transaction and persistence category patterns include: • Version Number: Provides a solution to maintain consistency and checks concurrency problems in the usage of use cases in an application. • JDBC for Reading: Performs listing of data in relational databases using JDBC. • Data-Access Command Beans: Is similar to EJB Command pattern that enables data access using Command beans. • Dual Persistent Entity Bean: Enables creation of entity bean that supports both Bean Managed Persistence (BMP) and Container Managed Persistence (CMP) through inheritance. ©NIIT Collaborate Lesson 1C / Slide 8 of 24
  9. 9. CollaborateThe TheServerSide.com Patterns(Contd.) • The client-side EJB interaction category patterns include: • EJB Home Factory: Improves the performance of EJB Home Interface by implementing caching with the use of EJB Home Factory. • Business Delegate: Reduces the coupling between the presentation and the business-tier. Business delegate pattern provides a proxy object to serve as an entry point to access business-logics and integration-tier data. ©NIIT Collaborate Lesson 1C / Slide 9 of 24
  10. 10. CollaborateThe TheServerSide.com Patterns(Contd.) • Following are the design patterns that are similar between J2EE pattern catalog and TheServerSide.com pattern catalog: • Service provided to Worker and Dispatcher View • Session Façade, Message Façade, and EJB Command • Service Locator and EJB Home Factory • Domain Data-Transfer Object, Custom Data-Transfer Object, Data- Transfer HashMap, and Data-Transfer RowSet • Value Object Assembler and Data-Transfer Object Factory • Data-Access Object and Data-Access Command Bean ©NIIT Collaborate Lesson 1C / Slide 10 of 24
  11. 11. CollaborateFrom the Expert’s Desk In this section, you will learn: • Best Practice on: • Guidelines for Developing Class Diagrams • Using Proven Design Patterns • FAQs on Legacy Systems ©NIIT Collaborate Lesson 1C / Slide 11 of 24
  12. 12. CollaborateBest PracticesGuidelines for Developing Class Diagrams • A UML class diagram depicts the static view of a system. • The view includes the classes and interfaces of the system, their inter- relationships along with the operations and attributes of the classes. • A Class diagram is used to analyze the requirements of the given system in the form of a conceptual model. • As class diagrams plays a vital role to identify the requirements for designing a software system, different styles are applied at different stages of software design. ©NIIT Collaborate Lesson 1C / Slide 12 of 24
  13. 13. CollaborateBest PracticesGuidelines for Developing Class Diagrams (Contd.) • General Guidelines • The general guidelines for developing class diagrams include: • Focus should be given on identifying the responsibilities for classes instead of the specific attributes or operations, while creating a domain class diagram. • Visibility of operations and attributes should be depicted in the detailed design model of the system. • The design model of a class diagram should reflect the naming convention of the implementing language, as it depicts the source code of the structure. • Depict the association classes in the analysis diagram so that it can be re-enforced in the design phase to enable implementation in languages that do not support native code for this concept. ©NIIT Collaborate Lesson 1C / Slide 13 of 24
  14. 14. CollaborateBest PracticesGuidelines for Developing Class Diagrams (Contd.) • Class Style Guidelines • Certain guidelines relating to naming a class are: • Class name should be realistic and should depict the real world object, for which the class is being made. • Class name should be a proper complete noun to make it more descriptive and easier to understand. • Operations should be named in a manner that clearly depicts the functionality that the operations represent. ©NIIT Collaborate Lesson 1C / Slide 14 of 24
  15. 15. CollaborateBest PracticesGuidelines for Developing Class Diagrams (Contd.) • Class Style Guidelines(contd.) • Certain guidelines relating to naming a class are(contd.): • Attributes should also be named precisely and clearly, so that the characteristics that the attributes represented are understandable. • The static operations/attributes should be listed before instance operations/attributes. • Operations names should be consistent among each other, to make the design easier to learn and understand. In addition, names of the parameter variables should be consistent. ©NIIT Collaborate Lesson 1C / Slide 15 of 24
  16. 16. CollaborateBest PracticesGuidelines for Developing Class Diagrams (Contd.) • Relationship Guidelines • Following are some guidelines regarding depicting relationships in class diagrams: • Dependency should be depicted when the relationship is transitory. • Depict the relationship as a tree, when both the classes have dependency relationship over the same class. • Avoid using ‘*’ to depict multiplicity on UML diagrams. • To simplify the diagram, it is always a good practice to depict the type of the attribute instead of depicting the relationship in the diagram. • Implied relationship should not be modeled that runs the risk of maintaining additional code. ©NIIT Collaborate Lesson 1C / Slide 16 of 24
  17. 17. CollaborateBest PracticesGuidelines for Developing Class Diagrams (Contd.) • Association Guidelines • The association guidelines to depict association relationship in a class diagram include: • A general convention is to center the name of the association over the association path, and the name of the association should be in active voice. • The reading direction of an association name should be same as the unidirectional relationship, to maintain consistency. • Role names should be indicated for the classes having multiple association relationships. ©NIIT Collaborate Lesson 1C / Slide 17 of 24
  18. 18. CollaborateBest PracticesGuidelines for Developing Class Diagrams (Contd.) • Inheritance Guidelines • Inheritance enables reuse of code and data. It models ‘is a’ and ‘is like’ relationships in a UML diagram. • Some of the guidelines are as follows: • It is a general convention to place a subclass under superclass in the diagram. • A subclass should inherit all the attributes and operations from its superclass. ©NIIT Collaborate Lesson 1C / Slide 18 of 24
  19. 19. CollaborateBest PracticesUsing Proven Design Patterns • Design patterns are one of the important reusable resources available to architects as well as to developers that help in designing and developing an efficient application. • Following are the core J2EE design patterns that are in frequent use in application development: • Session Facade: Provides an abstraction layer hiding all the underlying communication complexities in an EJB application. The use of session façade in an EJB application reduces remote method overhead by providing business components to act as interfaces to the clients. • Model view Controller: Decouples the data access, data presentation, and user interaction layers. As a result, high degree of maintainability and reusability among components is achieved. As the components are not tightly integrated to each other, several views can be added without affecting the underlying code and other components as well. ©NIIT Collaborate Lesson 1C / Slide 19 of 24
  20. 20. CollaborateBest PracticesUsing Proven Design Patterns (Contd.) • Value Objects: Provides a single representation of data needed by the EJB invocations. The number of remote calls is reduced by placing all the related data in a single implementation resulting in improved overall performance of the application. • Data Access Object: Encapsulates the access to the data source. It manages the connection established with the data source to access and store data. • Service Locator: Facilitates lookups for distributed components in an enterprise application. Service locator centralizes the lookup and provides handles to all the components. The use of service locator in an application reduces complexity, improves performance by supporting caching, and enables single point of control. ©NIIT Collaborate Lesson 1C / Slide 20 of 24
  21. 21. CollaborateFAQs • Why should one use patterns? Use of design patterns helps in optimizing the performance of enterprise applications. Each pattern describes a problem that occurs during the designing phase of an application, and then describes the solution to that problem. The solution to the problem is described in such a way that you can use this solution repeatedly. The knowledge of design patterns enables developers to directly refer to a particular named pattern during implementation and documentation phase of an application. It reduces the overhead of specifying individual classes, relationships, and collaborations that makes up a pattern. • What is an analysis pattern? Analysis pattern is a software pattern that is related to a business domain such as manufacturing, healthcare, and transportation. It enables discovering and capturing of business processes instead of language, structural, or implementation processes. ©NIIT Collaborate Lesson 1C / Slide 21 of 24
  22. 22. CollaborateFAQs (Contd.) • What are the main patterns utilized by Java APIs? Following are the main patterns utilized by the Java APIs: • Proxy pattern: Handles method invocations from a proxy object to a principal object. • Decorator Pattern: Enables transparency between class and its subclasses by extending the functionality of a class. • Factory Method: Provides the ability to create an object of a class without any dependency/relation. It delegates the choice of creating object of a class to another object. • Abstract Factory: Provides a way to instantiate an abstract class from the corresponding subclass ©NIIT Collaborate Lesson 1C / Slide 22 of 24
  23. 23. CollaborateChallenge 1. Match the following: a. Singleton i. Dynamically attaches responsibilities to an object b. Bridge ii. Defines representation of grammar for a given language for interpretation. c. Façade iii. Ensures that a class has only one instance. d. Decorator iv. Decouples abstraction from its implementation. g. Interpreter v. Provides a unified interface to a set of interfaces in a subsystem. • javax.ejb.EJBHome and javax.ejb.EJBLocalHome J2EE technology feature is associated with __________ pattern. • javax.ejb.EJBObject interface is associated with _____________ pattern. • Which GoF’s design pattern does the JMS Publish/Subscribe Model is associated with? ©NIIT Collaborate Lesson 1C / Slide 23 of 24
  24. 24. CollaborateSolutions to Challenge 1. a. – iii, b. – iv, c. – v, d. –i, e. –ii 2. Factory Method 3. Proxy Pattern 4. Observer design pattern ©NIIT Collaborate Lesson 1C / Slide 24 of 24