Compulsory course of Part 3, semester 2: SOFTENG 325 - "Software Architecture".

This course is distinctly divided into two parts, one about Java web stuff, and the other about "software engineering" in general, in an academic style. I think the course is badly-named (or badly-designed in general) - the Java web stuff doesn't seem very relevant to "software architecture".

  • Part 1: around Spring Framework
    • Dependency Injection
      • "Dependency Lookup", Inversion of Control
    • AOP (Aspect-Oriented Programming)
      • Jargon
        • joinpoint
        • pointcut (a set of joinpoints)
        • advice
        • aspect (advice + pointcut)
        • *advisor
        • proxy
        • introduction
      • AOP with Spring Framework
        • Programmatically
        • Declaratively
    • "Distributed Object Middleware" (Java RMI - Java Remote Method Invocation)
    • web services
      • Really basic TCP, HTTP
        • HTTP methods (aka verbs)
      • SOAP/WSDL
      • REST
    • ORM - Object-Relational Mapping/Mapper
      • Spring DAO (Data Access Objects)
      • Hibernate
    • Transactions
      • Various race conditions
        • Lost updates
        • Inconsistent retrievals
        • Dirty reads (read before other's commit/abort)
        • Premature writes (write before other's commit/abort)
        • "Repeatable read"
        • "Phantom read"
      • Serial Equivalence
      • Locking
        • 2-phase locking
        • exclusive lock
        • Read-write lock
    • "Security" (introductory cryptography)
      • Symmetric/Asymmetric key cryptography
      • digest hashes
      • certificates and digital signing
    • Basic concepts of Spring MVC
  • Part 2: software architecture
    • Quality attributes
      • The 6 system quality attributes:
        • Performance, Availability, Modifiability, Security, Usability, Testability
      • QAS: Quality attribute scenarios
        • concrete QAS
        • general QAS
    • "Structures" (which an achitecture often has many)
      • "Views" of a structure (which a structure often has many)
    • Common "tactics" for meeting quality requirements
      • (a few tactics for each of the 6 system QAs)
    • Architectural styles: examples
      • Client/server
      • Layered, or virtual machine
      • Pipe and filter
    • Creating architectures, given quality requirements
      • "ADD" - "Architecture-Driven Design"
    • Evaluating architectures
      • "ATAM" - "Architecture Trade-off Analysis Method"
        • "Utility tree"
    • Documenting architectures
      • "ADL" - "Architecture Description Language"
      • Maybe using UML
      • Document rationale, to allow for checking the architecture against quality requirements.
      • "Tailor to" different audiences/stakeholders
    • Software product lines: designing with variations
    • "Measuring modifiability"
      • OOP/OOAnalysis/OODesign: semantic coherence reduces potential changes
      • "CRS" - Class Reachability Set
        • CRSS - CRS size
      • "SCCS" - Strongly Connected Component Size
      • "towers" (at some large CRSS value) and "gaps" (between the tower and the vertical axis) (on the "class_count - CRSS value" histogram)
      • Large dependency cycles
    • Case study of Cecil, our "learning management system"
      • Examples of usages of tactics to meet quality requirements