1. Slide 1 Lecture 14 Enterprise Systems Development ( CSC447 ) COMSATS Islamabad Muhammad Usman, Assistant Professor

2. Slide 2 Performance Tactics

3. Slide 3 3 Performance Tactics Goal: Generate a response from the system within some time after receiving stimulus Two contributors –Resource Time –Blocked Time »Contention »Availability of resources »Dependency on others

4. Slide 4 4 Performance: Resource Demand Reduce resources per event –Increase computational efficiency –Reduce computational overhead Reduce the number of events –Manage event rate –Control sampling frequency –Bound queue sizes

5. Slide 5 5 Performance: Resource Management and Arbitration Management –Introduce concurrency –Maintain multiple copies of data or computation –Increase available resources Arbitration –Implement scheduling

6. Slide 6 6 Performance Tactics

7. Slide 7 7 Security Tactics

8. Slide 8 8 Security Tactics Resisting attacks Detecting attacks Recovering from attacks

9. Slide 9 9 Security: Resisting Attacks Authenticate users Authorize users Maintain data confidentiality (encryption) Manage integrity (checksums) Limit exposure – spread services among hosts Limit access – firewall

10. Slide 10 10 Security: Detection and Recovery Intrusion detection systems Recovery –State restoration (availability) –Attacker identification (audit trails)

11. Slide 11 11 Security Tactics

12. Slide 12 12 Usability Runtime, for the User –Separate user interface –Support user initiative »Cancel, undo, aggregate –Support system initiative »User model, System model, Task model Design Time –Separate UI from rest of design

13. Slide 13 13 Usability

14. Slide 14 View Based Documentation of Software Architectures

15. Slide 15 Uses of Documentation As a means of education – introducing people to the system As a primary vehicle for communication amongst stakeholders As a basis for system analysis

16. Slide 16 View types Architects need to look at software in three ways –How it is structured as a set of implementation units –How it is structured as a set of elements that have runtime behavior and interaction –How it relates to non-software structures and its environment

17. Slide 17 Viewtypes The module viewtype –Document a system’s principals units of implementations The component and connector viewtype –Document the system’s units of execution The allocation viewtype –Document the relationship between a system’s software and its development and execution environment

18. Slide 18 Styles In each view type there are a set of commonly occurring forms and variations – styles Layered style, client-server,..

19. Slide 19 Seven rules for sound Documentation Write documentation from the Readers’s Point of view Avoid unnecessary repetition Avoid ambiguity Use a standard of Organisation Record Rationale Keep documentation current but not too current Review Documentation for fitness of purpose

20. Slide 20 Viewtypes and Styles

21. Slide 21 Module Viewtype A code unit that implements a set of responsibilities Can be a class, a collection of classes, a layer or any decomposition of the code unit Has some properties: responsibility, visibility, author..

22. Slide 22 Module Viewtype styles Decomposition style Uses style Generalization style Layered style

23. Slide 23 Component and connector Viewtype Express runtime behavior Described in terms of connectors and components Objects, processes, collection of objects are components Pipes, repositories, sockets are connectors Middleware is a connector

24. Slide 24 C & C Viewtype Styles Pipe-and-filter Shared-data Publish-subscribe Client-server Peer-to-peer Communicating processes

25. Slide 25 Allocation Viewtype Maps software units to elements of the environment(hardware, development team..) Deployment style Implementation style Work assignment style

26. Slide 26 Style Guide Overview Elements, relations and properties What it’s for and not for Notations Relation to other views Examples

27. Slide 27 Viewtypes The module viewtype –Document a system’s principals units of implementations The component and connector viewtype –Document the system’s units of execution The allocation viewtype –Document the relationship between a system’s software and its development and execution environment

28. Slide 28 Module Viewtype A code unit that implements a set of responsibilities Can be a class, a collection of classes, a layer or any decomposition of the code unit Has some properties: responsibility, visibility, author..

29. Slide 29 Module Viewtype

30. Slide 30 Module Viewtype

31. Slide 31 Overview What is a module? – software units with well defined interfaces providing a set of services Module vs. component –Both are about decomposition –Module has a design time connotation and component a runtime connotation 4 common styles –The decomposition style – containment relationship among modules –The uses style – functional dependency relationships among modules –Generalization style – specialization relationships among modules –Layered style – allowed-to-use relation in a restricted fashion among modules

32. Slide 32 What is it for? Construction – –blueprint for the source code –Modules and physical structures (source code files) will have close mapping Analysis –Requirements traceability –Impact analysis Communication – useful for explaining the systems functionality

33. Slide 33 Notations

34. Slide 34 Modules in UML

35. Slide 35 Relationships in UML

36. Slide 36 What is it not for? Cannot make inferences about runtime behavior Hence not used for analysis of performance, reliability and other runtime qualities; we use c-and-c and allocation views are used

37. Slide 37 Relation to other viewtypes Module views commonly mapped to c-and-c viewtypes Sometimes one-to-one or one-to-many but could also be fragments to fragment

38. Slide 38 Module Viewtype styles Decomposition Style Uses Generalization Layered

39. Slide 39 Decomposition - overview Focus on the is-part-of relationship between elements and their properties How system responsibilities are partitioned across how these modules are decomposed into sub modules All architectures begin with module decomposition style – divide and conquer Useful for communicating the broad picture to new comers Since functionality is allocated, modifiability is immediately addressed

40. Slide 40 Criteria for decomposition Achievement of certain quality attributes –Modifiability –Performance Build-versus-buy decisions Product line implementations

41. Slide 41 Elements, Relations, Properties ElementsModules; an aggregation of modules is a subsystem RelationsDecomposition(is-part-of); criteria to be mentioned Element properties Defined in the module viewtype Relation Properties Visibility Topology No loops; A module cannot be part of more than one module

42. Slide 42 Informal Notations

43. Slide 43 UML Notations

44. Slide 44 Decomposition style What is it for? –Learning –New comers –Work assignment What is it not for? Notations –Named boxes within boxes –Textual notation Examples of decomposition style

45. Slide 45 From Clements etal

46. Slide 46 Relation to other styles Module decomposition view can be mapped into component-and- connector view; either one-to-one or one-to-many or fragment to fragment Closely related to work assignment style of allocation viewtype

47. Slide 47 Module Viewtype styles Decomposition Style Uses style Generalization Layered

48. Slide 48 Uses - overview What other modules should exist in order to do their part of the work properly

49. Slide 49 Uses summary ElementsModules RelationsUses relation Element propertiesDefined in the module viewtype Relation Properties Describe the kind of usage TopologyNo constraints; loops make incremental development difficult

50. Slide 50 Uses style contd. Can be documented as a two column table Or any graphical notation P1 uses P2, if P1’s correctness depend on the correctness of P2 kinds of usage –CALLS but not USES »Exception handling – just pass on the name of caller –CALLS and USES –No CALL yet USES »Expect P2 to leave a variable in a certain state

51. Slide 51 Where is it useful? Incremental development –Implement part of the total functionality Sub-setting, debugging, testing, impact analysis

52. Slide 52 Informal Notations

53. Slide 53 UML

54. Slide 54 UML

55. Slide 55 Decomposition Styles Decomposition Style Uses Generalization Layered

56. Slide 56 Overview Is-a relation is specialized to generalization Parent is a more general version of the child –In decomposition the parent consists of the child Useful for extension and evolution of architectures and individual elements Inheritance of interface and implementation

57. Slide 57 Generalization summary ElementsModules as defined in the module view type Relationsgeneralization relation Element properties Defined in the module viewtype; can also have some abstractions Relation Properties Distinguish between interface and implementation TopologyMultiple parents possible; cycles not allowed

58. Slide 58 UML

59. Slide 59 UML

60. Slide 60 Gen: where is it useful? Object-oriented designs Extension and evolution Local change or variation Reuse

61. Slide 61 Decomposition - Styles Decomposition Style Uses style Generalization Layered

62. Slide 62 Layered - overview Each layer represents a virtual machine Completely partitions the software Strict ordering Layer bridging

63. Slide 63 Layers summary

64. Slide 64 Layers - What is it for ? Modifiability Portability Principle of information hiding(VM) Run time overhead is more? –How to reduce it?

65. Slide 65 Relation to other styles Layers are not modules –A layer may be module –But modules can be decomposed to other modules; layers are not decomposed to other smaller layers – segmenting a layer gives rise to modules; modules can span layers

66. Slide 66 From Clements etal

67. Slide 67 UML

68. Slide 68 UML

69. Slide 69 69 Reference Bass, L., Clements, P. and Kazman, R., Software Architecture in Practice, Second Edition (2006), Addison-Wesley. Clements, P., Bachmann, F., Bass, L., Garlan, D., Ivers, j., Little, R., Nord, R. and Stafford, J., Documenting Software Architectures: Views and Beyond, 2002, Addison-Wesley. Documenting Software Architectures