Software Architecture: Design and Qualities

Software Architecture

• Refers to the broader structures of a software system
• Concerns how multiple software processes work together to achieve tasks
• Serves as a blueprint
• Provides an abstraction for managing system complexity
• Establishes communication and coordination among components
• Functions as the main carrier of system qualities like performance, security, and modifiability
• Achieved through a unified architectural vision

Factors of Software Architecture

• Quality Attributes
• Design
• IT Environment
• Human Dynamics
• Business Strategy

Design

• A plan or specification for constructing an object or system
• Used for implementing an activity or process
• The result of a plan or specification, such as a product, prototype or process.

Quality Attributes

• Includes correctness, reliability, adequacy, learnability, robustness, maintainability, readability, extensibility, testability, efficiency, portability.

IT Environment

• Integrated collection of technology components
• Caters to the needs of its users and the owner of the resulting system

Human Dynamics

• A team-oriented activity
• Involves engineers, developers, business analysts, domain experts, data/infrastructure architects, project managers, etc.

Business Strategy

• Refers to the actions and decisions a company undertakes to achieve its business goals
• Aims to be competitive in its industry

Software Design

• Provides a design plan
• Describes the elements of a system, their fit, and interaction to fulfill the system's requirements
• Objectives include negotiating system requirements and setting expectations with customers, marketing and management personnel
• Serves as a blueprint during development
• Guides implementation tasks, including detailed design, coding, integration, and testing

Goals of Architecture

• Expose the structure of the system
• Hide its implementation details
• Realize use-cases and scenarios
• Address the requirements of various stakeholders
• Handle both functional and quality requirements
• Improve the organization's market position
• Improve the quality and functionality offered by the system
• Improve external confidence in either the organization or system

Limitations of Software Architecture

• Lack of standardized ways to represent architecture
• Lack of analysis methods to predict whether it will accomplish requirements
• Lack of awareness of its importance
• Lack of understanding of the roles of software architects
• Poor communication among stakeholders.
• Lack of understanding of the design process
• Lack of design experience and evaluation of design

Roles of Software Architect

• Design Expertise: Expert with software design and methodologies.
• Domain Expertise: Expert on the system.
• Technology Expertise: Expert on available technologies.
• Methodological Expertise: Expert on software development methodologies such as SDLC

Common Quality Attributes

• Conceptual Integrity
  • Consistency and coherence of overall design, including components/modules
• Maintainability
  • System's ability to undergo changes
• Reusability
  • Capability for components/subsystems to be suitable for other applications
• Interoperability
  • Ability of systems to exchange information with ones written and run by external parties
• Manageability
  • Ease for system administrators to manage applications
• Reliability
  • Ability to remain operational over time.
• Scalability
  • Handle load increase without impacting system performance/size
• Security
  • Prevent malicious and accidental actions
• Performance
  • Responsiveness of executing actions within a given time
• Availability
  • Proportion of time the system is functional and working
• Supportability
  • Ability to provide helpful information for recognizing and fixing problems
• Testability
  • Ease for creating test criteria for the system and its components
• Usability
  • How well the application meets customer needs by being intuitive
• Correctness
  • Accountability for satisfying system requirements
• Portability
  • Functioning with different computing environments
• Integrality
  • Ability to make separately developed components work correctly together.
• Modifiability
  • Ease with which software accommodates changes
• Marketability
  • The system's use with respect to market competition
• Cost and Schedule
  • Costs with respect to time to market, lifespan, and utilization of existing systems

Architectural Style

• Called architectural pattern
• A set of principles for shaping an application
• An abstract framework for a family of systems
• Defines system in terms of structural organizations
• Provides a lexicon of components and connectors with rules
• Improves partitioning and allows design reuse by providing solutions to recurring issues
• Describes how to configure a collection of reusable components and connectors

Common Architectural Design

• Message Bus (Communication)
  • Software system that can use multiple communication channels.
• Services-Oriented Architecture SOA (Communication)
  • Applications use contracts and messages.
• Client/Server (Deployment)
  • The system is divided into two applications, client and server.
• 3-tier or N-tier (Deployment)
  • Separates functionality into segments on physically separate computers.
• Domain Driven Design (Domain)
  • Business objects are based on entities within the business domain.
• Component Based (Structure)
  • The application design is divided reusable components that expose communication interfaces.
• Layered (Structure)
  • Divide application into stacked groups of concerns
• Object Oriented (Structure)
  • Divide into objects each containing relevant data and behavior

Types of Architecture

• Business Architecture
  • Defines business strategy, governance, organization, and processes.
  • Focuses on the analysis and design of processes.
• Application (Software) Architecture
  • Serves as a blueprint for individual app systems and interactions.
  • Defines relationships to business processes.
• Information Architecture
  • Defines logical and physical data assets.
• Information Technology (IT) Architecture
  • Defines hardware and software building blocks.

Architecture Design Process

• Understand the Problem
• The most crucial step because affects the quality of the rest
• Identify Design Elements and their Relationship
• Build a baseline for the context of the system.
• Decompose to main components based on functions.
• Can be modeled using design structure matrix (DSM) for dependencies.
• Evaluate the Architecture Design
• Each attribute is estimated.
• Involves evaluating conformance to architectural quality attributes.
• Transform the Architecture Design
• Performed after evaluation.
• Change until quality attributes are satisfied.
• Choosing design solutions to improve quality while preserving domain.

Key Architecture Principles

• Build to Change Instead of Building to Last
• Reduce Risk and Model to Analyze
• Use Models and Visualizations as Communication and Collaboration Tool
• Use an Incremental and Iterative Approach

Key Design Principles

• Separation of Concerns
• Single Responsibility Principle
• Principle of Least Knowledge
• Minimize Large Design Upfront
• Do not Repeat the Functionality
• Prefer Composition over Inheritance while Reusing the Functionality
• Identify Components and Group them in Logical Layers
• Define the Communication Protocol between Layers
• Define Data Format for a Layer
• System Service Components should be Abstract
• Design Exceptions and Exception Handling Mechanism
• Naming Conventions