the vault

Modelling and Software Architecture

In progress.

Modelling

System modelling

Developing abstract models.

Formal models refer to mathematical models of a system which can be automatically verified.

System models are developed as part of both

  • requirements engineering: to help derive detailed requirements
  • system design: to describe system for implemnetation.

Abstraction

Leaving out details to make system easier to understand

Representation

Maintains all information of system being represented

Modelling Languages

  • UML
  • C4
  • Business Process Model and Notation (BPMN)
  • Systems Modelling Language (SysML)
  • Entity Relationship Diagram (ERD)

For UML diagrams, refer to Modelling for further explanation.

C4

Hierarchical diagrams:

  • system context: how software system in scope fits into the world around it
  • containers: zooms into software system in scope
  • components: zooms into individual components
  • code: (UML)

System context diagram shows the big picture of the system landscape, focusing on people, and software systems. The container refers to a separate runnable app - web application. The components are the decomposed containers, identifying major structural blocks.

System Architecture

Architectural design

Understanding how a software system should be organised and designing the overall structure of said system

Architecture reprsents significant decisions - from which significance is measured by cost of change.

Architecture, simplified is generally

  • how system is organised
  • how developers explain system at a high level
  • often considered significant at a higher level

Architecturally Significant Requirements

Requirements that have a measurable impact on the architecture

Functionality does not affect architecture - any architecture is able to implement the functionality. Architecture is mostly important for non-functional requirements.

Modifiability can be shown in three categories

  • Local change
  • Non-local change
  • Behavioural change

Conway's Law

Organisation which design systems are constrained to produce designs which are copies of the communication structures of these organizations.

Attribute-Driven Design

  1. Get ASRs
  2. Establish iteration goal
  3. Choose existing structure to improve within architecture
  4. Select multiple designs that might support ASR
  5. Instantiate patterns and tactics to the context
  6. Record design decisions
  7. Analyse partial design
  8. Iterate until satisfied

Architecture Patterns

Architectural pattern

An established architectural solution that might comprise multiple architectural tactics

Layered Architecture

Layered architecture

Structures the software system into individual grouping of modules that offer a cohesive set of services

Layer bridging

Using a upper layer using a module in a nonadjacent lower layer

Pros

  • Portability (layers can be general/specific)
  • Reusability (lower-level layers can be reused across applications)
  • Modifiability

Cons

  • Might get in the way by not providing all required lower-level abstractions
  • Performance penalties

Pipe-and-Filter Architecture

Pipe-and-filter-architecture

Consists of filters - processing components that take input, and produce output, and pipes - that connect filters together.

Pros

  • Modifiability: filters are independent
  • Reconfigurability: filters can be combined in differnet ways
  • Evolution: adding transformations is straightforward

Cons

  • Fixed format for data transfer
  • Performance: data must be output in specific format

Model-centered Architecture

Model-centered architecture

Components interact with a central model instead of each other

Pros

  • Components can be independent
  • Data can be managed consistently

Cons

  • Single point of failure (the model)
  • Distribution of repository may be difficult

MVC

  • Model

  • View

  • Controller

Pros

  • Highly modifiable
  • State can be managed and persisted
  • Concurrency

Cons

  • Upfront significant complexity
  • Burdensome for complex UIs

Plug-in architecture

Microkernel architecture is divided into a base system, and a set of plugin components, where plugins as a central concept form structure of subsystems.

Pros

  • Modifiability
  • Extensibility (can be developed by different teams to extend a core product)
  • Testability

Cons

  • Security concerns

Client-server Architecture

Client-server architecture

Server provides services to clients simultaneously.

Pros

  • Low coupling among server
  • No coupling among clients
  • Scalability
  • Evolvability

Monolith

Monolith

Single deployable unit

Service-oriented Architecture

Service-oriented architecture

Focus on independent (domain) services that are separately deployed

Pros

  • Deployability
  • Testability
  • Reliability

Microservice Architecture

Microservice

Collection of independently deployable services that communicate only via messages through service interfaces, that are typially stateless from small teams and code bases

Pros

  • Quick time to market/deploy
  • Independence
  • Scalability

Cons

  • Network communication overhead
  • Complex transactions
  • Different technologies with maintenance cost
  • Designing and maintaining multiple microservices can be challenging

Architectural Tactics

Architectural tactics

Assign decisions that influences a quality attribute

An architectural pattern might not solve the problem completely.

Availability Tactics

  • Detect faults
    • Monitoring
    • Ping/echo
    • Heartbeat: periodic message exchange between a system monitor and a process being monitored
    • Timestamp
    • Sanity checking: checks validity of specific operations on output based on knowledge of their internal structure
    • Voting
    • Exception detection
    • Self-test
  • Recover from faults
    • Preparation and repair
      • Redundant space: one or more duplicate components can step in if component fails
      • Rollback: revert to a previous, known good state
      • Exception handling
      • Software upgrade: in-service upgrade in a non-service affecting manner
      • Retry
      • Ignore faulty behaviours
      • Graceful degradation
      • Reconfiguration
    • Reintroduce system
      • Shadow: operate a component in a shadow mdoe
      • State resynchronisation
      • Escalating restart: automatic restart at different granularities
      • Nonstop forwarding
  • Prevent faults
    • Removal from service: temporarily place system component in an out-of-service state to mitigate
    • Transactions: provide ACID properties
    • Predictive models
    • Exception preventions
    • Increase competence set: set of states designed to operate correctly (even in the presence of out-of-memory-error situations, I/O errors, crashes)

Performance Tactics

  • Control resource demand
    • Manage work requests
    • Limit event response: queue or process items with delay
    • Prioritise events
    • Reduce computational overhead
    • Bound execution time
    • Increase efficiency
  • Manage resources
    • Increase resources
    • Introduce concurrency
    • Maintain multiple copies of computations
    • Maintain multiple copies of data: keeping separate copies of data to reduce contention
    • Bound queue sizes
    • Schedule resources: FIFO/fixed-priority/round-robin

Graph View

Backlinks