1. 3-tier System Design Recommendations

2. Recommendations Platform Capabilities & Restrictions Software Design Principles Requirement Specification (use cases) 3-tier System Design Recommendations 2

3. 3-tier Multilayer Reference Architecture 3-tier System Design Recommendations3

4. Design Assumptions We are creating business software system (business transaction processing system) 3-tier architectural style (Client, Application Server, DBMS) Relational DBMS Data consistency is more important than system performance (CAP theorem: CA is picked) Up to 1000-10000 concurrent users System will evolve in the future Actually, all systems have to evolve (more or less) But: not all developers do their best to enable easy system evolution (modifiability/extensibility)! 3-tier System Design Recommendations4

5. Design Questions Use case implementation should consist of how many components? How granular components should be? Of what type (stateless/stateful) components should be? How many components single web page should/may use? Should we create a separate component for each web page? 3-tier System Design Recommendations5

6. Restriction Example: Data Access Tier (Java EE and.NET) All Web Applications ARE multi-threaded ORM is not thread-safe.Net EntityFramework ObjectContext is not thread-safe too 1 One entity cannot be managed/shared by two EntityManagers The same holds for.Net ObjectContext One relationship cannot be managed/shared by two EntityManagers The same holds for.Net ObjectContext Problems of these kinds occur when Web pages belonging to a single use case use different components Approach “each Web page must have dedicated component” is problematic  1 Entity Framework FAQ: ObjectContextEntity Framework FAQ: ObjectContext 3-tier System Design Recommendations6

7. Recommendations – Outline The use case model is taken as an input, then for each use case: 1. Determine the use case type: Request, Conversation, Whiteboard 2. Design use case implementation (iterative process): 1. Decide what number of UI forms and business components is needed to implement the use case 2. Apply Software Design Principles (if business components violate some principles, restructure them) 3. Design with reuse in mind 3. Document the design decisions taken (UML) 3-tier System Design Recommendations7

8. How to Create a Use Case Model Different software processes dictate different approaches Recommendations for the second laboratory work: We start by modelling business process of the company BPMN diagram is created Business process contains steps performed manually steps performed with the help of the system being constructed (automated steps) Automated steps are candidates to become use cases (or groups of use cases) in the use case model 3-tier System Design Recommendations8

9. 1. Use Case Types: Request Single HTTP request is enough to implement the use case Usually one (or at most two) web pages: the first page has an HTML form collecting some data, the second shows the results Examples: Register a new student for a selected course Browsing through the web site (data are being presented in pages in read-only form) 3-tier System Design Recommendations9

10. 1. Use Case Types: Conversation A use case is of conversation type if: it needs several forms to be filled with data there is a clear beginning and an end of interaction with the user Conversation is somewhat similar to transaction (actually it is often called business transaction) either all conversation steps succeed, or all fail One conversation spans multiple HTTP requests Data collected in the beginning of the conversation must be remembered on the server-side till the end of the conversation 3-tier System Design Recommendations10

11. 1. Conversation Example 3-tier System Design Recommendations11

12. 1. Use Case Types: Whiteboard Whiteboard is the way to implement the use case when several users are allowed to work with the same data concurrently http://en.wikipedia.org/wiki/Whiteboarding Example: several users are editing the same document with Google Docs There is no clear beginning or end Need for synchronization arises: maybe I’m editing data that is removed already maybe the same data is being edited by several users new data appears constantly Use cases of whiteboard type obviously span multiple requests  We will not discuss this type further as it is not common for business software systems 3-tier System Design Recommendations12

13. 2. Design use case implementation Needed business logic (including data access/modification) is implemented in components Remember: Component technologies allow to separate business logic from middleware services Try hard to use one and the same cache for the whole use case implementation This way you will not get hit by ORM restrictions (e.g. trying to put the same entity object into two caches) => single cache owner is needed – Use Case Controller Use Optimistic Locking for long-lived entities! 3-tier System Design Recommendations13

14. Collaboration Example 3-tier System Design Recommendations14

15. 2. Apply Design Principles: Theory Most important design principles: Separation of Concerns (Wikipedia) – high-level principle, governing the whole set of more detailed principles (below)Wikipedia High cohesion (Wikipedia)Wikipedia Loose coupling (Wikipedia, contains good example)Wikipedia SOLID (Wikipedia)Wikipedia Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion GRASP (Wikipedia) – General Responsibility Assignment Software PatternsWikipedia 100 more principles Seriously, the whole Software Engineering theory is applicable here Most design principles will usually lead to some kind of decomposition We will decompose single business component into multiple components 3-tier System Design Recommendations15

16. 2. Design Principles: Architect vs. Developer Single class design is usually responsibility of developer, not architect Architect is responsible for high-level design, and design decisions that cross-cut the whole system Thus we will not talk further about SOLID and GRASP, but concentrate on how to apply principles of: Separation of Concerns (SoC) High Cohesion Loose Coupling to functional and non-functional requirements 3-tier System Design Recommendations16

17. 2. Principles: SoC and Cohesion Applying Separation of Concerns and High Cohesion principles to requirements specification we can distinguish these kinds of requirements 1 : Localizable functional requirements (implemented in SINGLE module) Example: Internal bank money transfer Crosscutting functional requirements (tend to be scattered throughout the whole code-base) Not-impacting cross-cut functionality (Observer Pattern): Example: if business transaction exceeds some money limit, inform Tax Inspection Impacting cross-cut functionality (Decorator Pattern) Example: if money are incoming from other bank, charge commissions Non-functional requirements (Wikipedia) (Interceptor/Proxy Pattern)Wikipedia They always are crosscutting! Examples: transactions, security checks, audit logging, etc.  1 Modularization of Crosscutting Concerns in Requirements Engineering, 2008 (PDF)PDF 3-tier System Design Recommendations17

18. 2. Kinds of Requirements: Example 3-tier System Design Recommendations18

19. 2. Loose Coupling Principle Techniques to achieve loose coupling are: Introduce stable interfaces between communicating components – ripple effect of changes stops at the interface boundary Separate the code that creates/configures component instances: Design patterns – Abstract Factory, Builder Dependency Injection (DI) techniques – CDI, Spring Framework Stable interfaces are still mandatory! Totally remove the dependency between the two communicating components: Event-driven techniques (CDI Events, Spring Framework Events, Actor model, …) Stable interfaces are still mandatory (event payload object has some interface)! 3-tier System Design Recommendations19

20. 2. Loose Coupling Principle Loose Coupling is very important for implementation of crosscutting functional requirements Modern technological platforms should provide means how to implement crosscutting functional requirements: Without code duplication (DRY principle) With loose coupling (or no coupling at all) 3-tier System Design Recommendations20

21. 2. Collaboration Example 3-tier System Design Recommendations21

22. 2. Consider Concurrency Patterns and Asynchronous Communication If use case implementation algorithm takes long time, consider splitting it to concurrently running parts Concurrency patterns help to choose best algorithm decomposition scheme Producer-Consumer, Work pool, Map-Reduce, Fork- Join, etc. Often communication between parts will have to be asynchronous 3-tier System Design Recommendations22

23. 2. Consider Concurrency Patterns and Asynchronous Communication Localizable functional requirements We may NEED asynchronous communication facilities (if computations take a long time) Crosscutting functional requirements Not-impacting cross-cut functionality (Observer Pattern): We may NEED asynchronous communication facilities Impacting cross-cut functionality (Decorator Pattern) We CANNOT have asynchronous communication here (by definition) Non-functional requirements We CANNOT have asynchronous communication here (by definition) 3-tier System Design Recommendations23

24. 2. Design for Reuse Use cases rarely are subject of reuse Thus Use Case Controller components do not have to be very reusable/adaptable and they can be stateful Use case parts (chunks of cohesive functionality) are mostly the same in all the systems targeting the same Application Domain, and are subject of reuse Example: Money transfer algorithm most probably is very similar in all Internet banking systems => Use case parts should be designed for reuse => Use case parts should be stateless (if possible) 3-tier System Design Recommendations24

25. 3. Documenting Design Decisions UI forms, business components and ORM entities may be represented in UML collaboration and sequence diagrams Following UML stereotypes are useful: «boundary» – denotes element that is used to interact with a user or external system (e.g. web page, WebService) «control» – denotes system element that performs some kind of business logic (implementation of functional or non-functional requirements) «Entity» – denotes some data/information entity 3-tier System Design Recommendations25

26. 3. Collaboration Example 3-tier System Design Recommendations26