Software Architecture & Design

• Software Architecture involves larger system structures, while Software Design focuses on the smaller, internal design of single software processes
• The design phase of the Software Development Life Cycle (SDLC) defines and documents software architecture
• A system's architecture describes its major components, relationships, and interactions, encompassing business strategy, quality attributes, human dynamics, design, and IT environment

Software Architecture

• It serves as a blueprint for a system, providing the structure
• It establishes communication and coordination among components while managing system complexity
• It defines a structured solution that meets technical and operational requirements, optimizing quality attributes like performance and security
• It involves significant decisions related to software development that can impact the organization

Key Decisions in Software Architecture

• Selection of structural elements and their interfaces
• Behavior in collaborations among elements
• Composition of structural and behavioral elements into subsystems
• Alignment of architectural decisions with business objectives.
• Architectural styles guide the organization

Software Design

• Software design provides a plan that describes the elements of a system and how they function together
• Objectives include:
• Negotiating system requirements and setting expectations
• Acting as a blueprint during development
• Guiding implementation tasks
• It follows domain analysis, requirements analysis, and risk analysis but comes before detailed design, coding, integration, and testing

Goals of Software Architecture

• To identify requirements affecting the application structure
• Reduces business risks, builds technical solutions, and bridges business with technical requirements
• Goals include:
• Exposing system structure while hiding implementation details
• Realizing use-cases and scenarios
• Addressing stakeholder requirements
• Handling functional and quality requirements
• Reducing ownership and improving market position

Limitations of Software Architecture

• It remains an emerging discipline
• Limitations:
• Lack of standardized representation tools
• Inability to predict implementation outcomes.
• Lack of awareness and understanding among stakeholders
• Difficulty in predicting project success based on architecture

Role of Software Architect

• Provides solutions for technical teams
• Requires expertise in:
• Design: Including object-oriented and event-driven approaches
• Domain: System expertise for software evolution.
• Technology: Knowledge of available technologies
• Methodological: Expertise in software development methodologies

Software Architect's Hidden Role

• Facilitates technical work, reinforces team trust.
• Shares knowledge and protects team members from distractions

Deliverables of the Architect

• Clear, complete and achievable goals
• Functional system description with decomposition layers
• System concept and design with decomposition layers
• Notion of timing, operator attributes, and plans for implementation/operation
• Document or process ensuring functional decomposition is followed and interfaces are controlled

Quality Attributes

• Attributes are properties separate from system functionality
• They affect runtime behavior, system design, and user experience
• Attributes are classified as static or dynamic

Static Quality Attributes

• Reflect system structure and organization and are related to architecture, design, and source code
• Affect development and maintenance costs but are invisible to end-users, including modularity, testability, and maintainability

Dynamic Quality Attributes

• Reflect system behavior during execution, related to system architecture, design, configuration, and platform
• Visible to end-users at runtime, like throughput, robustness, and scalability

Quality Scenarios

• Scenarios specify how to prevent faults from becoming failures, based on attribute specifications
• Components:
• Source: Internal or external entity that generates stimulus
• Stimulus: Condition that requires consideration upon arrival
• Environment: Context in which the stimulus occurs
• Artifact: processors, channels, storage etc
• Response: Activity after stimulus
• Measure: responses should be measurable, so requirements can be tested

Common Quality Attributes

• Design Qualities:
• Conceptual Integrity: Consistency and coherence of design.
• Maintainability: Ease of making changes
• Reusability: Ability to use components in other applications
• Run-time Qualities:
• Interoperability: Ability of different systems to operate successfully together
• Manageability: Ease of system administration
• Reliability: Ability to remain operational over time
• Scalability: Ability to handle increased load
• Security: Preventing malicious actions
• Performance: Responsiveness of the system
• Availability: Proportion of time the system is functional and working
• System Qualities:
• Supportability: Ability to provide helpful information for issue resolution
• Testability: Ease of creating test criteria
• User Qualities:
• Usability: Meeting user requirements intuitively, to satisfy the consumer
• Architecture Quality:
• Correctness: Accountability for meeting requirements
• Portability: Ability to run in different computing environments
• Non-runtime quality:
• Integrality: ability to components to work together correctly
• Modifiability: accommodation to changes
• Business qualities:
• Cost & schedule; the cost must respect market competition
• Marketability; the use of the system for the best in market

Architectural Style

• Architectural style, also called architectural pattern, is a set of principles that shape an application
• It defines an abstract framework for a family of systems in terms of structural organization
• It provides a lexicon of components/connectors, improves partitioning, and describes component configuration

Architectural Styles

• Each style describes a system category with
• Component types
• Connectors
• Semantic constraints
• Semantic models
• Topological layouts
• Common Architectural Styles:
• Message Bus
• Service-Oriented Architecture (SOA)
• Pipes and Filters
• Client/server.
• 3-tier or N-tier
• Domain Driven Design
• Separated Presentation
• Component Based
• Layered
• Object Oriented

Service Oriented Architecture (SOA)

• It is designed to build distributed systems
• It delivers services to other applications through a protocol
• It allows for reusability via interfaces & is not restricted by language or platform
• Architectures makes use of services available in the network, use common standards, and enable service integrations.
• It combines many components from existing services and provides design principles that structure system development
• SOA also integrates into decentralized systems

What is a Service?

• A unit of functionality that is self-contained and well-defined
• It exchanges information and uses a loosely coupled, message-based communication model

Service Connections

• A service consumer sends a request; provider sends a response
• Service connections are understandable to both

Service-Oriented Terminologies

• Services: Logical entities defined by interfaces.
• Service provider: Implements service specification
• Service consumer: Requests service from a provider
• Service locator: Registry that examines service provider interfaces
• Service broker: Passes service requests to additional service providers

Major Roles within SOA

• Service Provider: Maintains the service and makes it available.
• Service Consumer: Locates service metadata in the registry

Components of Service-Oriented Architecture

• The service-oriented architecture stack includes:
  • Functional aspects (transport, protocol, description, service, business process, registry),
  • Quality of service aspects(policy, security, transaction, management)

Quality of Service Aspects

• Policy – protocols used to provide services to consumers
• Security – the protocols used to identify & authorise
• Transaction – provides consistent results
• Management – set of attributes used to manage services

Characteristics of SOA

• Services are loosely coupled and are self-contained
• Supports interoperability and provides encapsulation, discovery, composition and reusability
• Facilitates Quality of Service (QoS) through Service Level Agreements (SLA)
• Has better scalability and availability due to location transparency
• It provides easier maintenance with reduced cost of development

Advantages of SOA

• Easy integration due to service specifications
• Managed complexity via isolated service specifications.
• Has platform independence and communicates through a shared language
• Loose coupling allows implementation without impacting services.
• Provides parallel development and easy availability, reliability and service reusability
• Offers easy maintenance because as each service is independent

Disadvantages of SOA

• Results in high overhead, when validating input it impacts performance
• Requires high investment & complex management because complex interactions occur

Practical Applications of SOA

• It is used in many everyday areas
• Used by air forces & the military for increasing situational awareness
• It aids in the development of healthcare & mobile applications like GPS functions
• It also functions in the maintenance of museums

Types of Architecture

• Business architecture- Business strategy
• Application (software) architecture- serves as a blueprint
• Information architecture- Data assets and management resources
• Information technology (IT) architecture- the hardware & software used to make up each system

Architecture Design Process

• Key inputs include the analysis of tasks and the hardware architecture
• Result includes an architectural description

Steps

• Understand the Problem- to create an effective solution
• Identify Design Elements & their Relationships- build a baseline to determine the context of each system
• Evaluate the Architecture Design- to determine if there is conformance to standards
• Transform the Architecture Design- to completely satisfy the quality attribute requirements

Key Architecture Principles

• Build to Change instead of Building to Last- build in flexibility for the future
• Reduce Risk & Analyze- UML is good to use, but do not let it suppress design
• communication & visualization
• Use Models & give an overview

Key Design Principles

• Separation of Concerns- divide each system into components
• Single Responsibility Principle- each module should have a job.
• Principle of Least Knowledge- the components & objects should not know each other, keeping them maintainable.
• Minimize Large Design Upfront- be careful when designing if there are unclear points.
• Do not Repeat the Functionality- code should be implemented one time
• Prefer Composition over Inheritance- this will not block free use of child classes, reducing hierarchies.
• Identify Components & group them in logical layers- this will help the system be easier to understand for the end user
• Define protocol between layers
• Define data format for each later
• should be abstract
• Handle exceptions/errors properly

Architecture Models

• UML object oriental modelling
• Architecture View Model; 4+1 for stakeholders and is an architecture verification method for documenting design, to cover all architecture aspects
• ADL defines architecture

UML

• It is a pictorial language to make blueprints
• Its functions are visualisation, specification, costruction and documentation
• Structural Diagrams
• Class
• Object
• Component
• Composite Structure
• Package
• Deployment
• Behavioural Diagrams
• Use Case
• Activity
• State Machine
• Sequence
• Interaction Overview
• Communication
• Time Sequenced

Architecture View Model

• A system with multiple views:
• Logical-object view
• Process-concurrency views
• Physical-mapping onto hardware
• Development-static structure and can be extended by adding one more view called scenario view or use case

Why is it called 4+1 & not 5

• Because the use case view has a special significance as it details the high level requirement of a system while other views details

Architecture Description Languages (ADLS)

• ADLs have syntax for a Language, they need to communicate as well as:
• Implementation
• Have ablity to represent styles
• Support analytical capabilities