1

SYSTEM & SOFTWAREARCHITECTURE

Elements, Definitions, Representation

2

Requirements

System Design

Detailed Design

Implementation

Installation & Testing

Maintenance

SW System DesignDocumentation

Module DesignDocumentation

4 Architecture Discipline

• Evolution “A technology typically evolves from being a craft to an engineering discipline over time with the infusion of scientific theory and the need for broad application.” [Boar]

5 Architecture Discipline

• Architecture - Research and Practice– Why - complexity, evolution, integration– What

a high-level structure and interfacesa framework for DRAIMME

– How - Methodology & Tools, Process, Culture

• Architecture Technology– From Specific System Architectures to Reference Architectures– From being a Craft to an Engineering Discipline– From Informal Specifications to Structured Documents to Formal ADLs and

Specifications– From Smart Designers to Licensed Architects

6 Levels of Abstraction

• Reference Architecture– An architecture for a CLASS of software system– May address only selected aspects– Describes design element types, constraints, rules

• Specific System Architecture– Provides a solution to a set of specific functional and

extra-functional requirements– It is a “complete” description which comprises a fully-

specified element instances and configurations

7 Reference Architectures:Levels• The Two Views:

– Conceptual View: architecture as a property-specific solution– Application/Functional View: architecture as a problem

specific solution• Conceptual Architecture

– Organizational principles– Structural elements, types of components – Interaction models– Properties

• Application/Functional Architecture– A domain/problem-specific refinement of a conceptual

architecture– Explicitly defined problem-specific functionality– Problem specific scenarios

8 Reference Architectures: Types• Architectural Styles

– Established patterns of system organization– Conceptual decisions: structure, component types, properties– Examples: pipes & filters, client-serve, layered systems

• Family Architectures– Architectures for classes of systems with common organization, solving problems

from a specific functional domain– Conceptual decisions influenced by the problem domain– Examples: Messaging System, Partner Product Family, DSSA

• Enterprise Architectures (consumer’s view)– Address the class of integrated systems of systems– A reference framework for DAIMME– The drivers: interoperability

• Business Domain Architectures – Middleware and applications

• Architectural Frameworks (developer’s view)– The drivers: reuse and interoperability – Multiple families– Common components => component-based development

9

Domain Model

Domain Architecture (reference architecture)

Architectural Frameworks

Specific System Architecture

Specific System Implementation

Specific SystemRequirements

Provides Requirements To

Prescribes the Development Of

Is the Blueprint For

Provides Requirements To

Architectural Styles

Guides

10

Domain ModelEnterprise Communication Systems

Common Software Platform (Middleware)

Business Communications Domain Architecture

Partner Partner II

Product Line Architecture Partner

Cross-Product Architecture

Integration Architecture

Generic Reference ArchitectureSmall Business Communication Systems

Directory A

Product Arch. Partner

Product Arch. Partner II

Software Infrastructure Arch.

Product Arch. Directory

Example: Architectural Framework

Common Svc.Directory

Specific System Architecture

Switch X Arch.

11 Role of Architecture in Development Process

Domain Data

Existing Architectures

Technologies

System Integration

Task

Domain Model

Domain Architecture

Specific System Task(Project Level)

Infrastructure

Domain Task System(s)

Customer Requirements Products

Environments

Legacy Systems

12 Role of Architecture in Development Process(2)

Domain Analysis

Domain Data

Existing Architectures (EA)

Technologies (T)Environments (E)

Domain Model (DM)

Domain Architecture

Design

Infrastructure Acquisition

Domain Architecture (DA)

Infrastructure

Legacy Systems (LS)

13 Architecture Representation • Documenting Architectural Decisions

Informal

Structured Documents Formal ADLs

• ADLs– Provide both a conceptual framework and a concrete syntax for

characterizing software architectures– Provide tools for editing, parsing, analyzing, simulating– Explore different aspects of the overall architectural design problem– Help to clarify the role and scope of architectural designs

• ADLs: Examples– UniCon - predefined medium-grained components, timing analysis – Aesop - style description– Rapid - focus on event-based systems, simulation facility– Wright - CSP-based language for specification and analysis – ACME- generic interchange language

14 GARM-ASPECT: Method

GARMA Set of Architecture

Modeling Abstractions: Concepts, Rules, Patterns, Guidelines

CORE TOOLArchE, d-ASPECT

ASPECTNotation for Representing

Architectural Elements: Architecture,Components, Contracts, Scenarios

ExternalTool

ExternalTool

ExternalTool

15 GARM-ASPECT:Overview• Conceptual basis - GARM (Generic Architecture Reference Model)

– Conceptsconstructive property-relatedabstractions

– Rules– Patterns– Guidelines– Aspects

• Notation - Architectural Elements– Templates for expressing constructive architectural concepts: architecture, component, interface,

port, contract, role– Rules and Properties– Types, subtypes and instances– Hierarchical decomposition

16 ASPECT: Architectural Elements

Scenario

Representation

Header

CBody

Liaison

Composite Primitive

Protocol

Header Body Interface

ContractComponent

Cluster

Architecture

Port

Role

Plays

Composition

Building Block

17

Example: DirSA- A Generic View

DirClient AdminDirClient SecurityServer

DirDataServer

RPC

SQLDAP

DAP

18

Component

ASPECT: Architectures

Scenario

Architecture

Rule-SetContract

1+2+

1+ 1+

DirSA: Architecture {Header {

Type:{Generic}POF: {}/*BCS Cross Product Architecture*/Instance:{}

}Components: {DirDataServer, DirClien, AdminDirClient, SecurityServer}Contracts {DAP, SQL, RPC}Rules {DirSARules.tex}Scenarios {DirSAConfig}

}

19 ASPECT: Component Types

Architecture

Cluster

ComponentConnector

Scenarios• Static• DynamicComponent

AtomicComponent

Rule-Set

20

ASPECT: Component Structure

Architecture

Connector

Scenarios• Static• Dynamic

Interface

. .

. .

Port

Port

Interface

Component

Body

Rule-Set

21 ASPECT: Cluster

ConnectorComponent

Architecture“Internal“

Can be more than one

ClusterComponent

Scenarios• Static• DynamicRule-Set

22 ASPECT: Contract

Architecture

Component

Scenarios• Static• Dynamic

.

.

. .

Role

Connector

Role

Liaison

Protocol

Rule-Set

23 ASPECT: Interconnect

Contract•Protocol

•Data

Rules

Component• Verbal Description

• References

Interface

. .

Interface• Data

. .

Role•Function•Parameters•Dependences•Dependability

Port•Function•Parameters•Dependences•Dependability

Port

Component• Verbal Description

• References

Interface•Data

Interface

. .

. .

Port

Port•Function•Parameters•Dependences•Dependability

Role•Function•Parameters•Dependences•Dependability

24

Example: Contract, Port• DS_AP : Port {• Type:{Generic}• Port_attr {• FA, DA: {ServiseProvide}• BA: {ServerDAP.wright}• QA: {SQualityControls.txt}• }

• }DUA_R DSA_RDAPPort

(AP)

DUA DSA

PortDS_AP

25 Integration: MSC

ArchE: Scenarios uBET: MCS

C.SRI.Send_req

Msc CSS.SPI.Rec_req

RPC

Out: Role requestorIn: role provider

C.SRI.Send_req

Msc CSS.SPI.Rec_req

Out: Role requestorIn: role provider

RPC

GLUE

Name: CS

C.SRISend_req RPC.requestor1 1.1

1.2 S.SPI.Rec.req RPC.provider

26

Software ComponentCode

Platform ComponentsApplication Components

Architecture Reuse Repository

•Archit. Agreements•Components

•Interfaces•Interaction Protocols•Refer. to DMS, CMS

(OCRA-Archie)

CMS

•Code

(Sublime)

DMS

•Documents(Compas)

Family Architecture

ApplicationArchitecture

PlatformDetailed Design

ApplicationDetailed Design

Platform Architecture

Spec & Documents

Spec & Documents

Documents

Software Components

CORPORATEASSETS

UNIFIED REPOSITORYSYSTEM

Product

Architecture

More Tools Integration

27

Example: OCRA Content Management

Scenarios

ReferenceAssociationFuture

Architecture

Domains

Components

Connectors

ProblemStatement

Cross-ProductArchitecture

Technical Prospectus

DocumentDescriptors

OtherDocuments

Rules

COMPASArchE

28 Conclusions• The proliferation of ADLs - Blessing or Curse?

– Types of architectures and representation needs– Architecture vies and their representation– Structural Core and Extensions

• Informal and Formal Representations– The “comfort” of documents– The benefits of formal descriptions

verification and analysismaintainabilitytransferabilitypoint of conformance

29 Conclusions• The People

– Switching to architecture-based development is a process of building new culture; it requires;

common understandingcommitmentprocess changesinvestment

– Switching to architecture-based development also requires mature methodology:

domain modelingarchitecture modelsnotationstools

– A good methodology allows good architectural designs but it does not necessitate them - good use of the methodology is required as well

30

End of Section 3a-1

coming up:structure charts