2. Usage of Patterns, RUP - J2EE Design, and RUP Implementation (Build) Nandan DasguptaTCJUG

3. 2 What is RUP?

4. 3 RUP - Use case Driven Product Development is Use case Driven: Use cases Test Verified by Implementation Implemented by Design Realized by Analysis Specified by User Docs

5. 4 RUP – Risk Driven Functional Requirements (Use cases) Business Quality Attribute Drivers Software Architecture Software analysis, design, development possess this Risks

6. 5 System Development – Overview Vision Requirements Architecture feeds drive Develop Buy a Vendor Product Modify an Existing System Usage of Developed Facility Implementation (Build/ Enhance, Integration and Testing) Deployment (Roll Out) analysis, decision, definition Design availability of resources availability in marketusage of Legacyaligning with policy Architecture ==Design Elements, Design Mechanisms, Run-Time Arch. analysis, decision, definitionblueprint Use case Analysis executables build

7. 6 RUP – Architecture Centric Requirements Architecture Implementation (Build/ Enhance, Integration and Testing) Deployment (Roll Out) Design Use case Analysis blueprintanswer question EVALUATIONEVALUATION  Build components which trace to design objects (and all the way back to use cases)  To identify and ensure defects are addressed prior to deployment  Configuration of run-time processing elements and software components, processes, and objects that live on them

8. 7 RUP – Iterative and Incremental Iterative: Repeat essentially the same process Incremental: Deliver usable functionality in chunks

9. 8 RUP Analysis & Design

10. 9 RUP Analysis & Design: Purpose Transform the requirements into a design of the system to be Evolve a robust architecture of the system Adapt the design to match the implementation environment

11. 10 Layered Architecture User Interface Responsible for presenting information to the actor and interpreting actor’s commands Application Responsible for implementing application specific logic using domain objects Domain Responsible for representing core business concepts, business processes and business rules Infrastructure Provides general technical capabilities that support the higher layers

12. 11 J2EE Architecture Presentation Tier Middle Tier (Domain Logic Layer and Data Layer) Web TierBusiness Tier Database Tier

13. 12 J2EE Architecture - Sample

14. 13 Model-Driven Design The model and the design shape each other The model is the backbone of a language used by all team members The model is distilled knowledge

15. 14 Model-Driven Design: Components Knowledge crunching Communication and the Use of Ubiquitous Language Binding Model and Implementation

16. 15 Knowledge Crunching Design together with domain experts Continuous learning Knowledge-Rich Design Deep Models

17. 16 Communication and Use of Language Ubiquitous Language One Team, One Language Documents and Diagrams  Written Design Documents  Executable Models  Overview Models

18. 17 Ingredients of Effective Modeling Binding the model and the implementation Cultivating a language based on the model Developing a knowledge-rich model Distilling the model Brainstorming and experimenting Using right tool

19. 18 Design Building Blocks Entities  Objects identified by their identity  Object definition focused on life cycle continuity and identity Value Objects  When focused on the attributes of an element, classify it as Value Object Services  Operation relates to a domain concept

20. 19 Design Building Blocks (cont.) Aggregates  Aggregate is a cluster of associated objects  Each Aggregate has a root and boundary  Boundary defines what is inside the Aggregate  Root is a single Entity contained in the Aggregate Aggregate Rules:  Root Entity has global identity and is responsible for enforcing invariants  Entities inside the boundaries have local identity  Objects within the Aggregate can hold references to other Aggregate roots  A delete operation must remove everything within the Aggregate  Keep associations between Aggregates minimal  Protect aggregate with Façade interface

21. 20 Design Building Blocks (cont.) Entities  Factories provide encapsulation of complex rules for creating Objects or Aggregates  Making client responsible for creating Objects and assembling the Aggregates to coupled design  Shift responsibility for creating complex Objects to a separate object which is part of the domain design Repositories  A client needs a practical means of acquiring references to pre- existing domain objects  Low level technical details must hidden from client

22. 21 RUP - J2EE

23. 22 RUP - J2EE

24. 23 RUP – Elaboration Phase  Proceed with J2EE up-front, not at the end  Refine the architecture and select components  Determine that Prototypes should include J2EE  Ensure Executable architecture should have J2EE tools selected  Determine Implementation Plan  Determine how many tiers  Define boundaries and boundary rules  Determine where J2EE components will be placed in packages/ subsystems  Design and programming guidelines should include J2EE specifics  Detail the Design  Model EJBs and other J2EE Technologies  Decide how to unit test EJBs  Choose only those J2EE technologies that are really needed

25. 24 RUP – Construction Phase  Refine/ Update the architecture and select components  Detail/ Update the Design  Model EJBs and other J2EE technologies  Provide J2EE development environment for all developers  Decide the right level of ceremony for the culture  Ensure Detailed modeling on risk areas, medium on non-risky  Implement J2EE patterns in first Iterations  Address Deployment issues early  Consider the importance of database design/ implementation

26. 25 J2EE Technologies RMI - Remote Method Invocation - Protocol for distributed communication Servlets - Java code which serves up dynamic web pages JSP - Combination of HTML and Java which can be intermixed JNDI - Java Naming and Directory Interface - Provides a common interface to communicate with different naming and directory services JDBC - Java Database Connectivity - Provides a common interface to heterogeneous data bases EJB - Enterprise Java Beans - Distributed Java Components, Stateless, Stateful, Entity and Message Driven

27. 26 J2EE Design Input from Analysis

28. 27 J2EE Design Input from Analysis (Use case Diagram)

29. 28 J2EE Design Input from Analysis (cont.) (Class Diagram)

30. 29 J2EE Design Input from Analysis (cont.) (Sequence Diagram)

31. 30 Design Patterns

32. 31 What is a pattern? Patterns  Problem/ Solution pairs in context Patterns facilitate reuse of successful software architecture and design Not Code Reuse; But  Solution/ Strategy reuse  Interface reuse

33. 32 Common Design Patterns Iterator  Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation Observer  Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically Proxy  Provide a surrogate or placeholder for another object to control access to it

34. 33 Creation Patterns Singleton  Ensure a class has one Instance, and provide a global point of access to it Abstract Factory  Provide an interface for creating families of related or dependent objects without specifying their concrete classes Creational Patterns prescribe the way that objects are created. These patterns are used when a decision must be made at the time a class is instantiated. Typically, the details of the classes that are instantiated -- what exactly they are, how, and when they are created -- are encapsulated by an abstract superclass and hidden from the client class, which knows only about the abstract class or the interface it implements.

35. 34 Structural Patterns Adapter  Convert the interface of a class into another interface that clients expect  Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces Structural Patterns prescribe the organization of classes and objects. These patterns are concerned with how classes inherit from each other or how they are composed from other classes. Proxy  Direct stand-in for another class, and it typically has the same interface as that of class because it implements a common interface Decorator  Extend the functionality of the original class in a way that is transparent to the client class

36. 35 Behavioral Patterns State  Allow an object to alter its behavior when its internal state changes Visitor  Represents an operation to be performed on the elements of an object structure  Visitor lets one to define a new operation without changing the classes of the elements on which it operates Behavioral Patterns prescribe the way objects interact with each other. They help make complex behavior manageable by specifying the responsibilities of objects and the ways they communicate with each other.

37. 36 Concurrency Patterns Single Thread Execution  Prevent concurrent calls to Objects that are not in an appropriate state to execute the method call Concurrency Patterns prescribe the way access to shared resources is coordinated or sequenced.

38. 37 Integrating Design Patterns for Designing an Application Framework

39. 38 Design Patterns for J2EE Model View Controller (MVC)  Fundamental Pattern for J2EE applications with a GUI Three categories of patterns implement MVC:  Presentation  Business  Integration

40. 39 Presentation Tier Patterns Intercepting Filter Front Controller Composite View View Helper Service to Worker Dispatcher View

41. 40 Front Controller Pattern Context  Web application with complex navigation Problem  Duplication of code if each view provides its own services  Risk of mixing presentation and navigation code Solution  Use of a Controller to handle all web requests  The controller works with a Dispatcher that handles navigation

42. 41 Front Controller Pattern (cont.)

43. 42 Service to Worker Pattern Context  Web application  Views are generated automatically from templates Problem  Processing common to multiple requests (e.g.: authentication) should be centralized  Generation of the view from the template should be made by a dedicated components Solution  Combination of a Dispatcher with a Controller, the views and the Helpers  Dispatcher: responsible for view management and navigation

44. 43 Service to Worker Pattern (cont.)

45. 44 Business Tier Patterns Business Delegate Service Locator Session Façade Value Object Composite Entity Value Object Assembler Value List Handler

46. 45 Business Delegate Pattern Context  Application where the business APIs are completely exposed to clients Problem  The whole API is exposed to client use ÜPresentation layer is tightly coupled to business implementation Solution  Use of a Business Delegate to hide Implementation Detail

47. 46 Business Delegate Pattern (cont.)

48. 47 Session Façade Pattern Session Bean provides unified approach Façade hides Entity Bean Details

49. 48 Integration Tier Patterns Data Access Object Service Activator User Workflow Integrator

50. 49 Data Access Object

51. 50 Value Object

52. 51 Detail the Design (Elaboration and Construction)

53. 52 ò Design shapes the system in a way that lives up to all requirements ò Results in a design model (s) ò Input to Implementation Create Design Class (es) that realizes the Use cases it is involved in and non-functional requirements defined in the Use cases - Account all technical implications and restrictions Assign the behavior of the Use cases to the Design Classes - Identify responsibilities and relationships ò Design can be divided into two segments òArchitectural design (Refine the Architecture) òImplementation Design (Detail the Design) Design

54. 53 RUP - J2EE Design

55. 54 Modeling Java Servlets in UML Modeled as ordinary Java Classes Use stereotypes to distinguish Servlet types = >

56. 55 Modeling JavaServer Pages in UML Modeled as Two Logical Entities A > is a class stereotype that abstracts the Web Page’s behavior on the Server A > abstracts the behavior of a Web Page on the Client

57. 56 Modeling EJB’s in the UML (External View Example)

58. 57 Modeling EJB’s in the UML (Internal View Example)

59. 58 Design Component (Construction)

60. 59 Component Component: A component is a named physical and replaceable part of a system that represents physical packaging of otherwise logical elements and that conforms to, and provides the realization of, one or more interfaces. A component type represents a piece of software code (source, binary, or executable) A component type has a type name A component instance represents a run-time code unit A component instance has a name and a type (component-name : component-type) A component is represented as a rectangle with two small rectangles protruding from its side

61. 60 Component Component: Physical packaging of model elements - Source, binary, executable, configuration, makefile, IDL bindings, etc. - Aggregate of other components Standard stereotypes - > - a program that may run on a node - > - consists of several executables - > - file containing source code or data - > - static or dynamic library - > - a document - > - HTML page - technology specific >, >, >, >, >

62. 61 Component Modelling Elements: Components Basic Class Object Interface Collaboration Use-case Active Class Component Node Composite Package Classes are basic model elements. Class names are shown in boldface type. Abstract classes are shown in italic. Object (Class Instance) are shown by class elements with underlined names. Interfaces are indicated by lollipops. Collaborations are indicated by dashed ovals. (They realize use-cases). Use-case is shown by ellipse. Active classes are shown by thick bordered class boxes.(They represent independent thread of processing). A Component is a combination of one or more classes that forms a physical software element. A Node is a processor or hardware device. A Composite Model element is a package or a subsystem of base or composite elements.

63. 62 Component Diagram A component diagram shows the dependencies among software components, including source code components, binary code components, and executable components. A component diagram has only a type form, not an instance form. A component diagram is a graph of components connected by dependency relationships.

64. 63 Component Diagram Components Implement Design Classes  Use cases are eventually realized as components (Code)  Components of the Implementation trace

65. 64 Component Diagram Component Characteristics Components trace to the model elements they implement (hence all the way back to use cases) A Component usually implements several elements Components provide the same interface as the model elements they implement Compilation dependencies denote which components are required to compile a specific component Implement component stubs to ease compilation, integration and test

66. 65 Design the Distribution (Construction)

67. 66 Deployment Diagram Deployment diagrams show the configuration of run- time processing elements and the software components, processes, and objects that live on them. Software component instances represent run-time manifestation of code units. Components that do not exist as run-time entities do not appear in Deployment diagrams.

68. 67 Deployment Diagram A deployment diagram is a graph of nodes connected by communication associations. Nodes may contain component instances; indicates “Component” run on nodes. Components may contain objects; indicates “Objects” is part of the component. Components are connected to other components by dashed-arrow dependencies.

69. 68 Deployment Diagram A Deployment Diagram shows the actual Hardware configuration consisting of Nodes (processors) Software - Components Processes Objects

70. 69 Deployment Diagram

71. 70 Q & A

72. 71 Bibliography  The Rational Unified Process-An Introduction - Philippe Kruchten  Use Case Modeling - Kurt Bittner, Ian Spence, Foreword by Ivar Jacobson  Writing Effective Use Cases - Alistair Cockburn  Design Patterns: Elements of Reusable Object-Oriented Software - Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides  Core J2EE Patterns - Deepak Alur, John Crupi, and Dan Malks  Applying UML and Patterns - Craig Larman  Building J2EE Applications with the Rational Unified Process - Peter Eeles, Kelli Houston, Wojtek Kozaczymski  Applied Java Patterns - Steven Stelting, and Olav Maasen  EJB Design Patterns - Floyd Marinescu  J2EE Web Services Design Patterns - Richard Katz

73. 72 Nandan Dasgupta nandan.dasgupta@wellsfargo.com Thank You