SYSTEM & SOFTWARE ARCHITECTURE

1. SYSTEM & SOFTWAREARCHITECTURE Elements, Definitions, Representation

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

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

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

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

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

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

8. Specific System Architecture Specific System Implementation Architectural Frameworks Domain Model Architectural Styles Provides Requirements To Guides Domain Architecture (reference architecture) Prescribes the Development Of Specific System Requirements Provides Requirements To Is the Blueprint For

9. Example: Architectural Framework Domain Model Enterprise Communication Systems Business Communications Domain Architecture Generic Reference Architecture Small Business Communication Systems Cross-Product Architecture Product Line Architecture Partner Common Svc. Directory Integration Architecture Switch X Arch. Product Arch. Partner Product Arch. Partner II Product Arch. Directory Software Infrastructure Arch. Specific System Architecture Partner II Directory A Partner Common Software Platform (Middleware)

10. Specific System Task (Project Level) Role of Architecture in Development Process System Integration Task Customer Requirements Products Domain Architecture Domain Data Domain Task Existing Architectures Domain Model Legacy Systems System(s) Technologies Infrastructure Environments

11. Role of Architecture in Development Process(2) Domain Analysis Domain Data Domain Model (DM) Domain Architecture Design Existing Architectures (EA) Domain Architecture (DA) Legacy Systems (LS) Technologies (T) Environments (E) Infrastructure Acquisition Infrastructure

12. Structured Documents Formal ADLs Informal Architecture Representation • Documenting Architectural Decisions • 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

13. GARM-ASPECT: Method GARM A Set of Architecture Modeling Abstractions: Concepts, Rules, Patterns, Guidelines ASPECT Notation for Representing Architectural Elements: Architecture, Components, Contracts, Scenarios CORE TOOL ArchE, d-ASPECT External Tool External Tool External Tool

14. GARM-ASPECT:Overview • Conceptual basis - GARM (Generic Architecture Reference Model) • 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

15. ASPECT: Architectural Elements Architecture Component Scenario Contract Header Liaison Role Header Body Interface Plays Port Composition Representation CBody Protocol Primitive Composite Cluster Building Block

16. Example: DirSA- A Generic View DirClient AdminDirClient SecurityServer RPC DAP SQL DAP DirDataServer

17. ASPECT: Architectures 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} } Architecture 1+ 1+ Rule-Set Component Contract Scenario 1+ 2+

18. Connector ASPECT: Component Types Architecture • Scenarios • Static • Dynamic Component Rule-Set Cluster Component Atomic Component

19. Connector ASPECT: Component Structure Architecture • Scenarios • Static • Dynamic Component Interface B o d y Port . . Rule-Set Port . . Interface

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

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

22. ASPECT: Interconnect • Component • Verbal Description • References • Component • Verbal Description • References • Interface • Data • Interface • Data • Port • Function • Parameters • Dependences • Dependability • Port • Function • Parameters • Dependences • Dependability . . . . Port Port . . . . • Contract • Protocol • Data Interface Interface • Role • Function • Parameters • Dependences • Dependability • Role • Function • Parameters • Dependences • Dependability Rules

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

24. Integration: MSC ArchE: Scenarios uBET: MCS Name: CS G L U E 1 1.1 C.SRISend_req RPC.requestor 1.2 S.SPI.Rec.req RPC.provider Msc CS C.SRI.Send_req S.SPI.Rec_req Msc CS RPC C.SRI.Send_req S.SPI.Rec_req Out: Role requestor In: role provider RPC Out: Role requestor In: role provider

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

26. Example: OCRA Content Management ArchE COMPAS Web-Based UI Problem Statement Architecture Technical Prospectus Document Descriptors Rules Scenarios Connectors Cross-Product Architecture Components Other Documents Domains Reference Association Future

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

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

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