Slide 1

Lecture 14

Enterprise

Systems

Development( CSC447)

COMSATS Islamabad

Muhammad Usman, Assistant Professor

Slide 2

Performance Tactics

Slide 33

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 44

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 55

Performance: ResourceManagement and Arbitration

• Management– Introduce concurrency– Maintain multiple copies of data or computation– Increase available resources

• Arbitration– Implement scheduling

Slide 66

Performance Tactics

Slide 77

Security Tactics

Slide 88

Security Tactics

• Resisting attacks• Detecting attacks• Recovering from attacks

Slide 99

Security: Resisting Attacks

• Authenticate users• Authorize users• Maintain data confidentiality (encryption)• Manage integrity (checksums)• Limit exposure – spread services among hosts• Limit access – firewall

Slide 1010

Security: Detection and Recovery• Intrusion detection systems• Recovery

– State restoration (availability)– Attacker identification (audit trails)

Slide 1111

Security Tactics

Slide 1212

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 1313

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

Elements Modules; an aggregation of modules is a subsystem

Relations Decomposition(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

Elements Modules

Relations Uses relation

Element properties

Defined in the module viewtype

Relation Properties

Describe the kind of usage

Topology No 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

Elements Modules as defined in the module view type

Relations generalization relation

Element properties

Defined in the module viewtype; can also have some abstractions

Relation Properties

Distinguish between interface and implementation

Topology Multiple 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 6969

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