Your SlideShare is downloading. ×
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
System
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

System

616

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
616
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
15
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • 2
  • 2
  • 2
  • 2
  • 2
  • Software Architecture: Diversity of Types Architectural Style [CMU] Enterprise Architecture [ECBS, TAFIM] Domain Architecture [NJIT, ECBS] DSSA [DoD, W. Trez] Product Line Architecture [B. Bohem] Specific System Architectural Designs OO Architecture [CORBA] Distributed Systems Architecture [ODP-RM] Taxonomy of Software Architecture Architectural Style : patterns or idioms for system organization Reference Architecture: an architecture for a class of software systems. It is a parameterized system model, composed of generic architectural elements that are replaced by “specific” ones when instantiated into a specific system architecture. Specific System Architecture: A high level design model of an actual software system, capturing architectural solutions that satisfy a given set of functional and extra-functional requirements. (This architecture serves as an input for the low level design phase of the development cycle.) Domain : An area of knowledge or activity. Domain Architecture: A reference architecture constrained by the needs and the specifics of the domain.
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 9
  • 2
  • 2
  • Transcript

    • 1. SYSTEM & SOFTWARE ARCHITECTURE Elements, Definitions, Representation
    • 2. Requirements System Design Detailed Design Implementation Installation & Testing Maintenance SW System Design Documentation Module Design Documentation
    • 3. Engineering Process Perspective Domain Model Domain Architecture Specific Systems & Infrastructure Domain Level Process Project Level Process Design Composes Prescribes Guides Constrains Guides Supports Constrains Requirements Implementation
    • 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 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. 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. Architectural Frameworks Domain Model Domain Architecture (reference architecture) Specific System Requirements Provides Requirements To Prescribes the Development Of Is the Blueprint For Provides Requirements To Architectural Styles Guides Specific System Architecture Specific System Implementation
    • 10. Example: Architectural Framework 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 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 Infrastructure Domain Task System(s) Customer Requirements Products Environments Legacy Systems Specific System Task (Project Level)
    • 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
      • 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
      Informal Structured Documents Formal ADLs
    • 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. 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. ASPECT: Architectural Elements Scenario Representation Header CBody Liaison Composite Primitive Protocol Header Body Interface Contract Component Cluster Architecture Port Role Plays Composition Building Block
    • 17. Example: DirSA- A Generic View DirClient AdminDirClient SecurityServer DirDataServer RPC SQL DAP DAP
    • 18. ASPECT: Architectures Component Scenario Architecture Rule-Set Contract 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 Component
      • Scenarios
      • Static
      • Dynamic
      Component Atomic Component Rule-Set Connector
    • 20. ASPECT: Component Structure Architecture
      • Scenarios
      • Static
      • Dynamic
      Interface . . . . Port Port Interface Component B o d y Rule-Set Connector
    • 21. ASPECT: Cluster Component Architecture “ Internal“ Can be more than one Cluster Component
      • Scenarios
      • Static
      • Dynamic
      Rule-Set Connector
    • 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_R DAP Port (AP) DUA DSA Port DS_AP
    • 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 G L U E Name: CS C.SRISend_req RPC.requestor 1 1.1 1.2 S.SPI.Rec.req RPC.provider
    • 26. More Tools Integration 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 Spec & Documents Documents Software Components CORPORATE ASSETS UNIFIED REPOSITORY SYSTEM Product Architecture
    • 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 Web-Based UI COMPAS ArchE
    • 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. 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. End of Section 3a-1 coming up: structure charts

    ×