Architectural Design of Distributed Business Systems

1. Architectural DesignofDistributed Business Systems Tutorial M3, TOOLS Europe 2001 13 March 2001 Trygve Reenskaug Mogul Norway AS, Oslo http://www.ifi.uio.no/~trygver Architectural Design of Distributed Systems

2. The Autokon systemfor the Computer-Aided Design of Ships 1960 - Architecture created 1962 - First deployed 1965 - First international 1997 - Converted to PC Architecture still valid!! Architectural Design of Distributed Systems

3. The Autokon architectureWhy the long life ? ¤ Shipbuilding essentially unchanged ¤ Luck - random access mass storage devices enabled database solution ¤ Reality reflected into Clean, intelligible modular structure ¤ Expressed user needs as symptoms for required abstractions Architectural Design of Distributed Systems

4. The Autokon architectureWas it worth it ? Y E S ! ¤ System integrity maintained through major revisions ¤ System reliability maintained through major revisions ¤ System is comprehensible to users and maintainers ¤ Architecture spans decades of development projects Architectural Design of Distributed Systems

5. ………………………………………. ………………………………………. ………………………………………. ………………………………………. ………………………………………. Exercise 1: What do WE mean by System Architecture? Architectural Design of Distributed Systems

6. Why architecture is important & What it is Habitable Architectures created for people Enterprise models Personal information environments System models, the heavy part UML Collaboration, a powerful abstraction for architectural topology Collaboration (role model) specify many instances CollaborationInstance depicting a concrete topology Patterns, a literary style for sharing experience Wrap Entity Beans with Session Beans Caterpillars Fate: Smooth transition from analysis to design Summary and Conclusion Highlights Architectural Design of Distributed Systems

7. WHY ARCHITECTURE? • Help create habitable systems • Help create long-lived, robust systems • i. e., aim for simplicity: • simple systems are easy to master • simple systems are easy to build - correctly • simple systems are easy to maintain Architectural Design of Distributed Systems

8. Theory X vs. Theory Y(MacGregor) Rigid,controllingenvironment Bored,passiveworkers Flexible,supportiveenvironment Interested,creativeworkers • Theory X: • Dislike work • Lack ambition • Are irresponsible • Are resistant to change • Prefer to be led rather than to lead • Theory Y • Are willing to work • Are capable of self-control • Are willing to accept responsibility • Are imaginative and creative • Are capable of self-direction Authoritarianleadership Inspiringleadership Architectural Design of Distributed Systems

9. Vision of Distributionanno 1973 Mary’s System Yngvar’s System Jonas’ System Kari’s System Anton’s System Architectural Design of Distributed Systems

10. A good conceptual model allows us to predict the effects of our actions. Without a good model we operate by rote, blindly. We do operations as we are told; we cannot fully appreciate why, what effects to expect, or what to do if things go wrong. The Importance of the User's Mental Model USER'SMODEL Designmodel USER DESIGNER SYSTEM SystemImage Donald A. Norman: The Design of Everyday Things Architectural Design of Distributed Systems

11. Make IT so simple that even a programmer can understand IT Edsger Dijkstra: • Testing can only show the presence of bugs • Testing can never show the absence of bugs • so, the number of bugs in the system when you deliver it is proportional to the number of bugsfound during testing • The only way to avoid bugsis not to put them in in the first place • I.E., Keep It Simple, Stupid (KISS) 60.000 bugs removed from Windows2000 during testing Architectural Design of Distributed Systems

12. Architectural styles Architectural Design of Distributed Systems

13. Architecture Example First Priority: Make it Habitable! Second Priority: Make it Buildable! Third Priority: Make it Cost Effective! Architectural Design of Distributed Systems

14. Software architecture encompassesthe set of significant decisionsabout the organization of a software system Selection of the structural elements and their interfaces Behavior as specified in collaborations among those elements Composition of these structural and behavioral elements into larger subsystems Architectural style that guides this organization Software architecture also involves Functionality, Usability, Resilience, Performance, Reuse, Comprehensibility Economic and technology constraints and tradeoffs Aesthetic concerns RATIONAL's Definition of Architecture"Principles of Architecting Software Systems" Architectural Design of Distributed Systems

15. Why architecture is important & What it is Habitable Architectures created for people Enterprise models Personal information environments System models, the heavy part UML Collaboration, a powerful abstraction for architectural topology Collaboration (role model) specify many instances CollaborationInstance depicting a concrete topology Patterns, a literary style for sharing experience Wrap Entity Beans with Session Beans Caterpillars Fate: Smooth transition from analysis to design Summary and Conclusion Highlights Architectural Design of Distributed Systems

16. Personal, Integrated Information Environments Enterprise level Work processes UML Object Model Personal level User's mental model UML Collaboration System level Design models All of UML Architectural Design of Distributed Systems

17. Enterprise levelExample:Travel Expense Enterprise level Work processes UML Object Model Architectural Design of Distributed Systems

18. Two Approachesto Object Orientation "East Coast Approach": Object orientation is a smart programming artifact. An object is an instance of a class. Simula; Master complexity; Classification Theory "West Coast Approach": Object Orientation is a powerful modeling paradigm. An object encapsulates state and behavior so that it cancollaborate with other objects. Smalltalk; Personal Information Systems; Computer Augmentation + Lisp + Simula (+ Operating Systems) Architectural Design of Distributed Systems

19. UML Instance Interaction DiagramTravel Expense Model Ruth 1: travelPermissionRequest (President) 4: authorizedExpenseReport Eve Douglas Adam (Software Manager) (Marketing manager) 2: travelPermission (Chief Accountant) Joyce Joe Elsie (Sales clerk) (Paymaster) (Programmer) 3: expenseReport Bill Bill Peter (Dispatcher) (Bookkeeper) (Technical author) 5: paymentRequest Kim Ann John (Methodologist) (Customer consultant) (Cashier) Architectural Design of Distributed Systems

20. UML Collaboration DiagramTravel Expense Model Ruth (President) / Traveler / Authorizer / BookKeeper / Paymaster Eve Douglas Adam (Software Manager) (Marketing manager) (Chief Accountant) Joyce Joe Elsie (Sales clerk) (Paymaster) (Programmer) Bill Bill Peter (Dispatcher) (Bookkeeper) (Technical author) Kim Ann John (Methodologist) (Customer consultant) (Cashier) Objects --> ClassifierRoles Architectural Design of Distributed Systems

21. Behavior: Action-Object Flow DiagramTravel Expense Model Travel perm.request <Decide> Travel permission <Buy tickets> Action <Travel> <Write exp. Report> Expense Report <Check OK><Authorize> Data Object AuthorizedExpense Report <Check> <Bookkeeping> Payment Request <Pay out> / Traveler / Authorizer / BookKeeper / Paymaster Who A Swimlane for each Object or ClassifierRole <Plan trip> What When Architectural Design of Distributed Systems

22. Pipes and Filters:Travel Expense Model TravelRecord[request] <Decide> TravelRecord[permission] <Buy tickets> <Travel> <Write exp. Report> TravelRecord[report] <Check OK><Authorize> TravelRecord[authorized] <Check> <Bookkeeping> TravelRecord[pay] <Pay out> / Traveler / Authorizer / BookKeeper / Paymaster Who <Plan trip> What Data Object changes state over time When Architectural Design of Distributed Systems

23. Personal Information Environment Personal level User's mental model UML Collaboration Architectural Design of Distributed Systems

24. Task: Decide permissionTravel Expense Model Travel perm.request Travel perm.request <Decide> <Decide> Travel permission Travel permission <Buy tickets> <Travel> <Write exp. Report> Expense Report <Check OK><Authorize> AuthorizedExpense Report <Check> <Bookkeeping> Payment Request <Pay out> / Authorizer / Traveler / Authorizer / BookKeeper / Paymaster <Plan trip> Architectural Design of Distributed Systems

25. Travel Permission Decision ToolTravel Expense System Traveler Peter Period week 11 Planned cost USD 2000.- Purpose Attend TOOLS Europe 2001 Current plan for Peter activity 1 activity 2 activity 3 week 10 11 12 13 14 15 Budget + commitments Item Budget Committed Travel 10,000 4,000 Permit Reject Architectural Design of Distributed Systems

26. Travel Permission Decision ToolRequired Topology / Planning Service Traveler Peter Period week 11 Planned cost USD 2000.- Purpose Attend TOOLS Europe 2001 Current plan for Peter Budget + commitments Item Budget Committed Travel 10,000 4,000 activity 1 activity 2 activity 3 week 10 11 12 13 14 15 / Accounting Service Permit Reject / Travel Service / DecisionTool / Authorizer Architectural Design of Distributed Systems

27. Architecting Distributed Systems System level Design models All of UML Architectural Design of Distributed Systems

28. Why architecture is important & What it is Habitable Architectures created for people Enterprise models Personal information environments System models, the heavy part UML Collaboration, a powerful abstraction for architectural topology Collaboration (role model) specify many instances CollaborationInstance depicting a concrete topology Patterns, a literary style for sharing experience Wrap Entity Beans with Session Beans Caterpillars Fate: Smooth transition from analysis to design Summary and Conclusion Highlights Architectural Design of Distributed Systems

29. EnterpriseProduction Planning & Control Architectural Design of Distributed Systems

30. UML Use Case NotationDemo Example UC 1: Generate test networks User (Me) UC 2: Frontload UC 3: Allocate resource ActivityNetworkDemo Architectural Design of Distributed Systems

31. Use Case 2: FrontloadingUML Instance Interaction Diagram 9:fL(19) 1:fL(0) 4:fL(10) 7:fL(16) 2:fL(6) 5:fL(13) 3:fL(6) 8:fL(17) 6:fL(13) fL(t) = public void frontLoad (int time ) Project 0---20 Activity-B 7(4)10 Activity-D 14(3)16 Activity-F 18(2)19 Activity-A 1(6)6 Activity-C 7(7)13 Activity-E 14(4)17 Architectural Design of Distributed Systems

32. The UML Collaborationand the ClassifierRole / RoleName 2: mess2 1: mess1 A collaboration describes how an operation, like a use case, is realized by a set of classifiers and associations used in a specific way. The collaboration defines a set of roles to be played by instances, as well as a set of interactions that define the communication between the instances when they play the roles. Architectural Design of Distributed Systems

33. The essence of frontloadingCollaboration with Interaction / Predecessor / Successor / Activity fL(t1) fL(t2) * * * * A many-relation (*) means that the role represents a typical member of the setAll other members behave correspondingly "In an instance of a collaboration, each ClassifierRole maps onto at most one object.” Architectural Design of Distributed Systems

34. Interfaces in theBasic scheduling collaboration / Predecessor / Successor / Activity fL(t1) fL(t2) «Interface» FrontloadIntf frontLoad(time) The interfaces specify minimal requirements to receiving classes Architectural Design of Distributed Systems

35. Interface DefinitionsJava / Predecessor / Successor / Activity fL(t1) fL(t2) «Interface» FrontloadIntf frontLoad(time) public interface FrontloadIntf { public void frontLoad (int t);} Architectural Design of Distributed Systems

36. The UML Classplaying a role in a Collaboration :ClassName 2: mess2 1: mess1 An Instance of a given class playing the specified role at run time Architectural Design of Distributed Systems

37. Assign classes to roles(Optional) / Predecessor:Activity, :Project / Successor:Activity, :Project / Activity : Activity fL(t1) fL(t2) «Interface» FrontloadIntf frontLoad(time) Architectural Design of Distributed Systems

38. Class DefinitionsJava / Predecessor: Activity, Project / Successor: Activity, Project / Activity : Activity fL(t1) fL(t2) «Interface» FrontloadIntf «Interface» BackloadIntf frontLoad(time) backload(time) public class Activity implements FrontloadIntf { private FrontloadIntf[] successors; … … … public void frontload (int t) {…} … … … } public class Project implements FrontloadIntf{ private FrontloadIntf[] startActivities; … … … public void frontload (int t) {…} … … … } Architectural Design of Distributed Systems

39. Why architecture is important & What it is Habitable Architectures created for people Enterprise models Personal information environments System models, the heavy part UML Collaboration, a powerful abstraction for architectural topology Collaboration (role model) specify many instances CollaborationInstance depicting a concrete topology Patterns, a literary style for sharing experience Wrap Entity Beans with Session Beans Caterpillars Fate: Smooth transition from analysis to design Summary and Conclusion Highlights Architectural Design of Distributed Systems

40. Separate Presentation and BusinessObjects paint(); WEB Browser Button Tool ActivityGraph BarChart Project activity-B activity-D activity-A Activity-F activity-C activity-E Architectural Design of Distributed Systems

41. An UnrealisticImplementation class ActivityGraph extends Canvas {. . . public void paint(Graphics g) { . . . // paint frame etc. Graphics ng = g.create(. . .); tool.getProject().paintGraph(ng); } public class Project {. . . public void paintGraph(Graphics g) { // collect ranked activities Activity[][] bucket = rankedActivities(); // Plot activities in each column. for (int i=0; i < bucket.length; i++) { for (int j=0; j < bucket[i].length; j++) { bucket[i][j].paintSymbol(g, new Point (…), grid); } } // draw connections . . . Architectural Design of Distributed Systems

42. Java RMIRemote Method Invocation Client paint(); Server Information Bus WEB Browser Button Tool ActivityGraph BarChart Project activity-B activity-D activity-A Activity-F activity-C activity-E Exercise 3: Suggest an implementation for this system Architectural Design of Distributed Systems

43. The UML Subsystemplaying a role in a Collaboration SubsystemName 2: mess2 1: mess1 A subsystem is a grouping of model elements that represents a behavioral unit in a physical system. A subsystem offers interfaces and has operations. Architectural Design of Distributed Systems

44. High level Collaborationwith Subsystems Tool paint(); PlanningService WEB Browser Button Applet ActivityGraph BarChart Project activity-B activity-D activity-A Activity-F activity-C activity-E Architectural Design of Distributed Systems

45. The UML Componentplaying a role in a Collaboration ComponentName 2: mess2 1: mess1 A Component represents a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces. Architectural Design of Distributed Systems

46. High level Collaborationwith UML Components Tool paint(); «Interface» Project PlanningService ? WEB Browser Button Responsibility Applet ActivityGraph BarChart Project activity-B activity-D Responsibility activity-A Activity-F activity-C activity-E Architectural Design of Distributed Systems

47. Assign Componentsto Physical Nodes Tool Application Server PC Planning Service Architectural Design of Distributed Systems

48. A Collaboration describes how an operation, like a use case, is realized by a set of classifiers and associations used in a specific way. The collaboration defines a set of roles to be played by Instances, as well as a set of interactions that define the communication between the instances when they play the roles. The Instance is encapsulated. It has identity, interface and state. An instance of a given Class can play one or more roles at run time.A ClassifierRole can be implemented by many ways. A Subsystem is a grouping of model elements that represents a behavioral unit in a physical system. A subsystem offers interfaces and has operations. A Component represents a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces. A Node is a run-time physical object that represents a computational resource, Some UML Definitions Architectural Design of Distributed Systems

49. Build-time Diagrams (Code and Code Management) Class Diagrams Deployment Diagrams Component Diagrams Run-time Diagrams Use Case Diagrams Collaboration Diagrams (Objects, ClassifierRoles, Subsystems, Components) Interaction & Sequence Diagrams Object Diagrams Statechart Diagrams Activity Diagrams / Action-Object Flow Diagrams UML Diagrams(Architecturally Significant) Architectural Design of Distributed Systems

50. Why architecture is important & What it is Habitable Architectures created for people Enterprise models Personal information environments System models, the heavy part UML Collaboration, a powerful abstraction for architectural topology Collaboration (role model) specify many instances CollaborationInstance depicting a concrete topology Patterns, a literary style for sharing experience Wrap Entity Beans with Session Beans Caterpillars Fate: Smooth transition from analysis to design Summary and Conclusion Highlights Architectural Design of Distributed Systems