1. 1 SYSTEM & SOFTWARE ARCHITECTURE Elements, Definitions, Representation

2. 2 Requirements System Design Detailed Design Implementation Installation & Testing Maintenance SW System Design Documentation Module Design Documentation

3. 3 Engineering Process Perspective Domain Model Domain Architecture Specific Systems & Infrastructure Domain Level ProcessProject Level Process Requirements Design Implementation Composes Prescribes Guides Constrains Guides Supports Constrains

4. 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. 5 Architecture Discipline Architecture - Research and Practice – Why - complexity, evolution, integration – What a high-level structure and interfaces a 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. 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. 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. 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. 9 Domain Model Domain Architecture (reference architecture) Architectural Frameworks Specific System ArchitectureSpecific System Implementation Specific System Requirements Provides Requirements To Prescribes the Development Of Is the Blueprint For Provides Requirements To Architectural Styles Guides

10. 10 Domain Model Enterprise Communication Systems Common Software Platform (Middleware) Business Communications Domain Architecture Partner Partner II Product Line Architecture Partner Cross-Product Architecture Integration Architecture Generic Reference Architecture Small 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. 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. 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. 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. 14 GARM-ASPECT: Method GARM A Set of Architecture Modeling Abstractions: Concepts, Rules, Patterns, Guidelines CORE TOOL ArchE, d-ASPECT ASPECT Notation for Representing Architectural Elements: Architecture, Components, Contracts, Scenarios External Tool External Tool External Tool

15. 15 GARM-ASPECT:Overview Conceptual basis - GARM ( G eneric A rchitecture R eference M odel) –Concepts constructive property-related abstractions –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. 16 ASPECT: Architectural Elements Scenario Representation Header CBody Liaison Composite Primitive Protocol HeaderBody Interface ContractComponent Cluster Architecture Port Role Plays Composition Building Block

17. 17 Example: DirSA- A Generic View DirClient AdminDirClientSecurityServer DirDataServer RPC SQL DAP

18. 18 Component ASPECT: Architectures Scenario Architecture Rule-Set Contract 1+ 2+ 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. 19 ASPECT: Component Types Architecture Cluster Component Connector Scenarios Static Dynamic Component Atomic Component Rule-Set

20. 20 ASPECT: Component Structure Architecture Connector Scenarios Static Dynamic Interface. Port Interface Component BodyBody Rule-Set

21. 21 ASPECT: Cluster Connector Component Architecture “Internal“ Can be more than one Cluster Component Scenarios Static Dynamic Rule-Set

22. 22 ASPECT: Contract Architecture Component Scenarios Static Dynamic. Role Connector Role Liaison Protocol Rule-Set

23. 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 Function Parameters Dependences Dependability Role Function Parameters Dependences Dependability

24. 24 Example: Contract, Port DS_AP : Port { Type: {Generic} Port_attr { FA, DA: {ServiseProvide} BA : {ServerDAP.wright} QA: {SQualityControls.txt} } DUA_RDSA_R DAP Port (AP) DUA DSA Port DS_AP

25. 25 Integration: MSC ArchE: Scenarios uBET: MCS C.SRI.Send_req Msc CS S.SPI.Rec_req RPC Out: Role requestor In: role provider C.SRI.Send_req Msc CS S.SPI.Rec_req Out: Role requestor In: role provider RPC GLUEGLUE Name: CS C.SRISend_req RPC.requestor11.1 1.2S.SPI.Rec.req RPC.provider

26. 26 Software Component Code Platform Components Application Components Architecture Reuse Repository Archit. Agreements Components Interfaces Interaction Protocols Refer. to DMS, CMS (OCRA-Archie) CMS Code (Sublime) DMS Documents (Compas) Family Architecture Application Architecture Platform Detailed Design Application Detailed Design Platform Architecture Spec & Documents Documents Software Components CORPORATE ASSETS UNIFIED REPOSITORY SYSTEM Product Architecture More Tools Integration

27. 27 Example: OCRA Content Management Scenarios Reference Association Future Architecture Domains Components Connectors Problem Statement Cross-Product Architecture Technical Prospectus Document Descriptors Other Documents Rules COMPASArchE

28. 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 analysis maintainability transferability point of conformance

29. 29 Conclusions The People –Switching to architecture-based development is a process of building new culture; it requires; common understanding commitment process changes investment –Switching to architecture-based development also requires mature methodology: domain modeling architecture models notations tools –A good methodology allows good architectural designs but it does not necessitate them - good use of the methodology is required as well

30. 30 End of Section 3a-1 coming up: structure charts