Software Architecture

Software Architecture

1. Set off structures needed to reason about the system.

2. Abstraction of a system that selects specific details.

3. Representation

   • Documentation, Source code… architecture known to everyone

4. Views

   • Set of elements itself, as they exist in software or hardware.

5. Structure

   • Set of elements itself, as they exist in software or hardware.
     • Module Structures
       • Split into modules(code or data) that have to be constructed
       • Static way of considering the system
       • Functional responsibility
       • Ex: What is the primary functional responsibility assigned to each module?
       • Decomposition Structure, User structure, Layer structure, Class structure, Data model
     • Component-and-connector structures
       • Run-time behavior
       • Component: Peers, clients, servers, filters, etc.
       • Connector: call-return, pipes, etc.
       • Ex: How does data progress through the system?
       • Service structure, Concurrency structure
     • Allocation Structures
       • How the system will relate to non software (CPU's, file systems, networks, etc.)
       • Relation between internal and external components
       • Ex: What processor does each software element execute on?
       • Deployment structure, Implementation structure, Work assignment structure

6. Architectural patterns

   • Layered
     • Uses relation is unidirectional
   • Shared data (repository)
     • Compromises components and connectors that create, store and access persistent data
   • Client-server
     • Components are clients and servers, and the connectors are protocols and messages
   • Multi-tier pattern
     • Distribute and allocate components in subsets of hardware and software connected by communications.
   • Competence center and platform
     • Work is allocated to sites depending on their expertise.

7. System Architecture

   • Representation of a system mapping of functionality onto hardware and software components, and human interaction with these components.

8. Enterprise Architecture

   • Organization's processes, information flow, personnel, and organizational subunits and the interaction with these components

9. Process Recommendations

   • Product of a single architect or a small group with a leader
   • Well specified quality attribute requirements
   • Documented using views
   • Evaluated for its ability to deliver the system's important quality attributes
   • Incremental Implementation

10. Structural Rules

    • Well defined-modules
    • Use well-known architectural patterns and tactics
    • Never depend on other product or tool
    • Separate modules that consume data from modules that produce data
    • Don't except 1to1 correspondence between modules and components
    • Processes could be altered between processor with ease
    • Small number of ways for components to interact
    • Specific and small contention areas