unit1-ppt-01-t1-ch1-abc

8/3/2019 Unit1-ppt-01-T1-Ch1-ABC

http://slidepdf.com/reader/full/unit1-ppt-01-t1-ch1-abc 1/43

Architecture

Business Cycle

Shubha Raj K.B.



2

Outline

Introductions

Vasa

Architecture Business Cycle

Advice and Rules of Thumb for "Good"

Architecture



3

Preliminary Definition

The software architecture off a program or

computing system is the structure or

structures off the system,, which comprisesoftware elements,, the externally visible

properties off those elements,, and the

relationships among them..



4

History of the Vasa

January 1625: Initialcontract

Early 1626: Accelerated

schedule as buildingcommenced

Later 1626: Ship sizeincreased

1627: Shipwright died August 1628: Maiden

voyage



5

Schedule Pressure

Original project was to take 4 years

Shorter schedule demanded by King

Ship builders opted to extend small ship

rather than start over



6

Changing Requirements

King asked for larger size to

accommodate more guns

Eventually asked for 2 decks of guns



7

No Written Specifications

Original ship was familiar to ship builders

Scaling up was done without written

specifications



8

No Written Plan

3 "managers" worked without written plans

Shipwright died during project

400 people working in 5 different groups:

largest project in Sweden at this time



9

Missing Science

17th century ship builders could only

measure stability and heeling

characteristics by trial Center of gravity could not be predicted

accurately



10

Cross-Section of Vasa



11

Result:



12

The Role of Architecture

Traditionally,, Requirements beget design, which begets

system. Software Architecture,,encompasses the structures of large software

systems.



13

Architecture as a Tool

An important tool for:Communication

Reasoning

Analysis

Growth

And, ... Publication!



14

Where do Architectures come

from?

Stake holders:

• The customers

• The end users

• The developers

• Marketing people

• The developer’s organization

• The maintenance organization, …

•Architectures are influenced by system

stackholders

•Architectures are influenced by technical andorganizatinal factors



15

The stakeholder’s concerns:

Providing a certain behavior at runtime

Performing well on a particular piece of hardware

Being easy to customize Achieving a short time to market

Low cost of development

Gainfully employing programmers who have a

particular specialty



16

Architectures are influenced by technical and

organizational factors

Architecture is the summary result of a set of business and technical

decisions.

Architects design will vary depends on many factors Deadlines, real-time system, hardware, support software, human resource,

tools, etc …

Different stakeholders has different concerns and goals, some of them

may be contradictory

Structures and nature of the organization

In general, the influences are: customers and end users

Developing organization

Background and experience of the architect

Technical environment



17

Influences on Architecture

System

Architecture

Customer

And end user

Architect’s influence

Developing

organization

Technical Environment

Architect’s Experience

Architect(s)

Requirements (Qualities)



18

Influences on the Architecture



19

Stakeholders

Developing Organization

Management

Marketing

End User

Maintainenace

Organization

Customer



20

Developing Organization

Structure and Nature

Staffs Skill's

Schedule and Budget

Three Categories: Immediate Business

Long-term Business

Organizational Structure



21

Architect's Experience

Education and training

Exposure to successful architectural

patterns

Exposure to systems that have worked

particularly

Wish to experiment



22

Technical Environment

The environment that is current when anarchitecture is designed will influence that

architecture.. It is a brave architect who, in today's

environment, does not at least consider aWeb based, object-oriented, middleware-supported design for an informationsystem.



23

Requirements

Identify and actively engage the stakeholders

Architecture reviews Iterative prototyping

More than just technical skill's

DiplomacyNegotiationCommunication



24

Architecture Business Cycle

Stakeholders

Developing

Organization Technical

Environment

Architect's Experience



25

Effects on Dev. Org..

Teams are formed for individual software units

Schedules and budgets allocate resources in

chunks corresponding to the units Families off similar systems

Establish a foothold in a particular market area



26

Other Effects

The customer may be willing to relax

some requirements to gain economy

Architect's experience with subsequentsystems

Change the software engineering culture



27

Activities around Architecture

Creating business case

Understanding requirements

Creating or selecting architecture Documenting and communicating architecture

Analyzing architecture

Implementing system Ensuring conformance of implementation



28

Creating the business case for

the system It is the important step in creating and constraining

any future requirements

How much should the product cost?

What is its targeted market?What is its targeted time to market?

Will it need to interface with other systems?

Are there system limitations that it must work

within?



29

Understanding the requirements

Object oriented analysis

Safty-critical systems Creation of proto types



30

Creating or selecting the architecture

Any design process, there will be

multiple candidate design

Some will be rejected immediately Some will contend for primary

Choosing the right one is the architects

greatest challenges



31

Representing and communicating the

architecture

Communicate clearly, unambiguously to all stakeholders Developers must understand the work assignments Testers must understand the task structure Management must understand the scheduling implications

Representation medium should be: informative unambiguous readable by many people with varied background

Architecture must meet:behavioral, performance, quality requirement

Representation medium can serve as input to:

formal analysis techniques such as model building, simulation,verification, rapid prototyping

ADL - Architecture Description language



32

Analysis or evaluating the architecture

ADL provides analytical capabilities for runtime

properties of the system

Its performance

Its behavior

Its communication patterns, etc …

Non runtime quality attributes as:

Maintainability. ( portability, reusability, adaptability)



33

Implementing based on architecture and

ensuring conformance

Concerned with keeping the developers faithful

to the structures and interaction protocols

Requirements:Well communicated architecture

Environment or infrastructure to assists the

developers

Tools for architecture development

Constant vigilance for maintenance



34

What Makes a Good

architecture?

There is no absolute good or bad!

Architectures are either more or less fit for

some stated purpose.. Architectures can in fact be evaluated but

only in the context off specific goals



35

"Good" Architecture Rules of

Thumb (1/3)1. Use information hiding to hide computing

infrastructure

2. Each module should protect its secretswith a good interface

3. Use well-known architecture tactics to

achieve quality attributes



36


Thumb (2/3)4. Minimize and isolate dependence on a

particular version of a commercial

product or tool.5. Separate producer modules from

consumer modules.

6. For parallel-processing, use well-definedprocesses or tasks.



37


Thumb (3/3)7. Assignment of tasks or processes to

processors should be easily changeable

(even at runtime)8. Use a small number of simple interaction

patterns



38

Architecture Process Advice

(1/3)1. Architecture should be product of a single

architect of small group with identified leader

2. Architect should have functional requirementsand a prioritized list of quality attributes

3. Architecture should be well-documented with

at least one static and one dynamic view



39


(2/3)4. Architecture should be circulated to

stakeholders, who are active in review

5. Architecture should be analyzed(quantitatively and quality) before it is too

late.



40


(3/3)6. System should be developed

incrementally from an initial skeleton that

includes major communication paths7. Architecture should result in a small

number of specific resource contention

areas



41

Structural Guidelines (1/2)

Information-hiding modules

Well-defined interfaces

Quality attributes Independent off a particular version off a

commercial product or tool

Modules that produce data should be separatefrom modules that consume data..



42

Structural Guidelines (2/2)

A smallll number off simple interaction

patterns

For parallel processing systems:Well-defined processes or tasks

Assignment to specific processors should be

changed

unit1-ppt-01-t1-ch1-abc

Documents