Connor's Notes

⬅️ Back to portfolio

COSC 4P01: Lecture 9 Notes

4 min read

Note

Starting at week 4 slides, slide 34

Architectural design

Architectural patterns

Pipe and filter architecture

  • functional transformations process their inputs to produce outputs
  • may be referred to as a “pipe and filter model” (in UNIX shell)
  • data is transformed → forwarded to next stage of processing
  • used when: data processing applications (batch & transaction-based) where inputs are processed in separate stages to generate related outputs
  • advantages:
    • easy to understand and supports transformation reuse
    • workflow style matches structure of many business processes
    • evolution by adding transformations is straightforward
    • can be implemented as a sequential or concurrent system
  • disadvantages:
    • format for data transfer has to be agreed upon between communicating transformations
    • each transformation must parse its input and un-parse its output to the agreed form
      • increases system overhead and may mean it is impossible to reuse functional transformations that use incompatible data structures
flowchart LR
    A[Invoices] --> B(Read issued invoices)
    C[Payments] --> D(Identify payments)
    B --> D

    D --> E(Issue receipts)
    E --> F[Receipts]

    D --> G(Find payments due)
    G --> H(Issue payment reminder)
    H --> I[Reminders]

Application architectures

  • meta system which supplies a framework to the business
  • businesses have much in common → their application systems also tend to have a common architecture that reflects the application requirements
  • generic application architecture: an architecture for a type of software system that may be configured and adapted to create a system that meets specific requirements
  • contains common elements for the app domain
  • within this meta application, we can have design patterns to implement the system at the architectural level

Uses of application architectures

  • as a starting point for architectural design
  • as a design checklist
  • as a way of organizing the work of the development team
  • as a means of assessing components for reuse
  • as a vocabulary for talking about application types

Examples of application systems

Data processing applications

Transaction processing applications

  • E-commerce systems
  • reservation systems
  • process user requests for information from a database or requests to update the database
  • from a user perspective, a transaction is any coherent sequence of operations that satisfies a goal
    • e.g. find the times of flights from London to Paris
  • users make async requests for service which are then processed by a transaction manager

Event processing system

Language processing systems

  • command interpreters - XML to new document format - XML to extract a query which defines an SQL match
  • accept a natural or artificial language as input and generate some other representation of that language
  • may include an interpreter to act on the instructions in the language that is being processed
  • used in situations where the easiest way to solve a problem is to describe an algorithm or describe the system data
    • meta-case tools process tools descriptions, method rules, etc. and generate tools

flowchart TD
    SL["Source language instructions"] --> T["<div style='font-weight:700'>Translator</div><div style='border-top:1px solid #999;margin:4px 0'></div>Check syntax<br/>Check semantics<br/>Generate"]
    T --> AM["Abstract m/c instructions"]
    AM --> I["<div style='font-weight:700'>Interpreter</div><div style='border-top:1px solid #999;margin:4px 0'></div>Fetch<br/>Execute"]
    D["Data"] --> I
    I --> R["Results"]

Note

End of week 4 slides, moving on to week 5

Design & Implementation

Build or buy

  • in many domains, it is now possible to buy off-the-shelf systems (COTS) that can be adapted and tailored to the users requirements
  • design becomes figuring out how to morph the package to the business needs
  • is building it yourself more beneficial than buying a premade system?
    • consider cost, dev time, maintenance, etc.
  • disadvantages to buying:
    • package restrictions (functional limitations)

OO design

  • requires several models
  • context model
    • can provide the super class with defines the major components of the system
    • provides context to how the system will interact with the environment

Object class identification

  • grammatical approach

Note

take notes up to slide 26

Note

Ended at week 5, slide 26

Graph View