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

Slide 2 Performance Tactics

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

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

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

Slide 6 6 Performance Tactics

Slide 7 7 Security Tactics

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

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

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

Slide Security Tactics

Slide 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

Slide Usability

Slide 14 View Based Documentation of Software Architectures

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

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

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

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

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

Slide 20 Viewtypes and Styles

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..

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

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

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

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

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

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

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..

Slide 29 Module Viewtype

Slide 30 Module Viewtype

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

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

Slide 33 Notations

Slide 34 Modules in UML

Slide 35 Relationships in UML

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

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

Slide 38 Module Viewtype styles Decomposition Style Uses Generalization Layered

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

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

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

Slide 42 Informal Notations

Slide 43 UML Notations

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

Slide 45 From Clements etal

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

Slide 47 Module Viewtype styles Decomposition Style Uses style Generalization Layered

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

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

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

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

Slide 52 Informal Notations

Slide 53 UML

Slide 54 UML

Slide 55 Decomposition Styles Decomposition Style Uses Generalization Layered

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

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

Slide 58 UML

Slide 59 UML

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

Slide 61 Decomposition - Styles Decomposition Style Uses style Generalization Layered

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

Slide 63 Layers summary

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

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

Slide 66 From Clements etal

Slide 67 UML

Slide 68 UML

Slide 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