Day Fifteen: Software Architecture

Chapter 4 in our textbook, Software Development An Open Source Approach, reintroduces many themes and ideas that were previously mentioned in several earlier computer science courses. The recurrence of this information suggests that it is vital to good software engineering practices. For this blog post, I will provide a brief outline of chapter 4, mainly for my benefit, but also for the benefit of others.

4.1  Architectural Patterns

• Multi-Tier pattern: "GUI components are isolated within the user interface layer and database interactions are isolated within the database layer."
• Client-Server pattern: "separates the functionality of a typical user of the system from that of the server that hosts the database that all users access."
• Transaction Processing pattern: "useful for systems that accept a stream of transactions and process each transaction fully before moving on to the next." ex. ATM
• Model-View-Controller (MVC) pattern: "separate the functionality (the model) that underlies the user interface form the code that controls how the user sees (the view) and interacts with (the controller) the system."

4.2  Layers, Cohesion, and Coupling

• The Layering Principle: "each component appears in a single layer; the user sits at the top layer and the database is at the bottom layer."
• "allows developers to visualize the system as a small umber of interconnected vertical layers."
• The Maximum Cohesion Principle: "All the functions that relate to a single concept are gathered into a single module or class. A software architecture is maximally cohesive if all its modules and classes are cohesive in this way."
• The Minimum Coupling Principle: "Two modules are coupled if either one shares information or receives services directly from the other. A software system is minimally coupled when the number of interaction between all pairs of modules is kept to a minimum."

4.3  Security

• "The first step in ensuring security is to understand the client's requirement that the new software protect confidential and other sensitive information form unauthorized access. A software security policy must be defined for the new system that implements that requirement, and the software must incorporate that policy in a transparent and verifiable way."

4.3.1  Architectural Vulnerabilities

• "Common types of software flaws that lead to vulnerabilities include:"
• "Memory safety violations, such as buffer overflows and dangling pointers"
• "Input validation errors, such as format string bugs, SQL injection, code injection, e-mail injection, directory traversal, cross-site scripting in Web applications, HTTP header injection, and HTTP response splitting."
• "Race conditions, such as time-of-check-to-time-of-use bugs and symlink races"
• "Privilege-confusion bugs, such as cross-site request forgery in Web applications, clickjacking, and FTP bounce attack"
• "Privilege escalation"
• "User interface failures, such as user conditioning, blaming the victim, and race conditions"

4.3.2  User-Level Security

• "When reviewing the security aspects of a software system, we need to ensure that the system enforces the following constraints on users:"
• "Each authenticated user has a unique login id and password, and access to all system functions is provided only after the person enters his/her id and password
• "Each authenticated user has access to only those system functions that are appropriate for their level of access, and no others."
• "Each visitor to the system has access only to those system functions that are appropriate for the general public to access."

4.4  Concurrency, Race Conditions, and Deadlocks

• Many synchronization problems can be avoided with a technique called "locking"
• Locking: "Any session accessing a resource (table or row) in a database gains exclusive control of (a "lock" on) that resource throughout the time required to complete that access (read, write, or update). If a second session tries to access the same resource while the first session has a lock on it, the second session's request is put into a queue until the lock is released. All requests for access to the same resource are handled in a first-come-first-served order."