Software architecture design principles

• Architecture design is problem-solving that uses the SRS document as input.
• The output of architecture design is the abstract specification of software, with the aim of realizing the desired characteristics.
• The architecture design specifies the solution's components, their responsibilities, properties, relationship, and collaboration.
• Architectural design activity overlaps with SRS Analysis (Product Design) and Detail Design Activities.
• Overlap occurs because of the 4 design principles: Feasibility, Adequacy, Changeability, and Economy.

Feasibility

• During product design, feasibility of specific architecture may need understanding.

Adequacy

• To demonstrate the sufficiency of the solution, creation of an architectural prototype during Product Design or Design Analysis time may be needed.

Changeability

• Trade-offs of requirements may need to be based on the design architecture.

Economy

• May be necessary to explore schedule, cost, and resource impact based on the design architecture along with some detail design.
• All architectural designs vary in terms of their level of abstraction.
• Designs can vary in the number of components, description of components, and component relationships.
• Deciding on the correct level of architectural depth is a common problem.

Considerations

• Problem Context: The more the problem's size, the more of abstraction levels, components, and relationships among components are needed.
• Organizational context: More experienced and sophisticated organizations typically have more standards, tools, and skills, which can lead to predetermined design preferences or constraints in the architectural design,.

Architectural Design Process

• The Swift Engineering Design process begins with SRS.
• This leads to design analysis, then architectural design and detail design.
• This transforms into design documentation.
• The architectural design process involves developing and evaluating architectural alternatives.
• It also requires selecting an architectural resolution before finalizing the software architecture document (SAD).

Software Architecture Document (SAD)

• The SAD Template includes a product overview, architectural models, and mapping between models.
• Architectural design rationale is also included in the SAD.

Product Overview

• Summarizes the product, stakeholders, target market, assumptions, constraints, and basic business requirements.

Architectural Models

• Presents the architecture in terms of data models, functional decomposition, activities, system states, and transitions.
• It represents the aspects or views, often using the DeSCRIPTR framework as a guide.

Mapping between Models

• Presents and explains how the different models relate to each other.

Architectural Rationale

• It explains design decision criteria, investigated alternatives, and reasons for the architectural choice.

Non-Functional Requirements

• Functional requirements can be mapped into key architectural components.
• Non-functional requirements are quality attributes which include: operational attributes and development attributes.

Operational Attributes

• Performance includes time limits, space capacity, and transaction limits.
• Availability is the readiness for use.
• Security encompasses resistance to and protection from harm.
• Reliability is error resistance and performing to requirements.
• Usability involves being easy to understand and navigate.

Developmental Attributes

• Maintainability is easy to understand and modify.
• Reusability includes being portable, easy to modify, and having loose coupling.

Finger Print Matching

• An example program matches fingerprints from scanners against a database to control facility access.
• The program has to respond quickly, be available, perform matching reliably, and resist attackers.
• Input validation and fingerprint validation are key components.

Non-Functional Attribute Implementation

Performance

• "Respond quickly" is a performance attribute consideration.
• It must be determined which functionality, such as input validation or fingerprint validation, requires review.
• The scanner or database as a potential bottleneck must be considered.
• The speed criteria should be specified on the activity diagram.

Availability

• "Must be available the entire time" is an availability consideration.
• Redundancy on the activity diagram should be specified.
• A backup scanner needs to switch too.
• A redundant data base is required.
• A redundant processor would be required.

Reliability

• "Must perform matching at a reliable rate" is a reliability consideration.
• Input checking cannot accept incomplete or smeared fingerprints.
• Algorithms for digitizing fingerprints and comparing the database must be accurate, considering error rates.
• These aspects must be specified on the activity diagram.

Security

• "Must resist attacker" is a security consideration.
• The entire system must be physically protected without external connections.
• Security check functionality is needed for start-up, shut-down, and access.
• Security checking can be added as additional functionality to the activity diagram.

Cohesion

• Cohesion relates to issues with component functions.
• Input and fingerprint validation should each have single related functions.