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

Lecture 14

Enterprise

Systems

Development( CSC447)

COMSATS Islamabad

Muhammad Usman, Assistant Professor

Performance Tactics

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

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

Performance: ResourceManagement and Arbitration

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

• Arbitration– Implement scheduling

Performance Tactics

Security Tactics

Security Tactics

• Resisting attacks• Detecting attacks• Recovering from attacks

Security: Resisting Attacks

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

Security: Detection and Recovery• Intrusion detection systems• Recovery

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

Security Tactics

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

Usability

View Based Documentation of Software Architectures

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

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

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

Styles

• In each view type there are a set of commonly occurring forms and variations – styles

• Layered style, client-server, ..

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

Viewtypes and Styles

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

Module Viewtype styles

• Decomposition style• Uses style• Generalization style• Layered style

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

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

Allocation Viewtype

• Maps software units to elements of the environment(hardware, development team..)

• Deployment style• Implementation style• Work assignment style

Style Guide• Overview• Elements, relations

and properties• What it’s for and not

for

• Notations• Relation to other

views• Examples

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

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

Module Viewtype

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

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

Notations

Modules in UML

Relationships in UML

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

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


• Decomposition Style• Uses• Generalization• Layered

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

Criteria for decomposition

• Achievement of certain quality attributes– Modifiability– Performance

• Build-versus-buy decisions• Product line implementations

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

Informal Notations

UML Notations

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

From Clements etal

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


• Decomposition Style• Uses style• Generalization• Layered

Uses - overview

• What other modules should exist in order to do their part of the work properly

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

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

Where is it useful?

• Incremental development– Implement part of the total functionality

• Sub-setting, debugging, testing, impact analysis

Informal Notations

Decomposition Styles

• Decomposition Style• Uses• Generalization• Layered

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

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

Gen: where is it useful?

• Object-oriented designs• Extension and evolution• Local change or variation• Reuse

Decomposition - Styles

• Decomposition Style• Uses style• Generalization• Layered

Layered - overview

• Each layer represents a virtual machine• Completely partitions the software• Strict ordering• Layer bridging

Layers summary

Layers - What is it for ?

• Modifiability • Portability• Principle of information hiding(VM)• Run time overhead is more?

– How to reduce it?

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

From Clements etal

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

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

Documents

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