The document discusses architectural design decisions in software engineering, highlighting the complexity and importance of these choices in addressing architecturally significant requirements. It distinguishes between implicit and explicit but undocumented design decisions and outlines the tools available for decision-making, such as QOC and various software engineering tools. Additionally, the document emphasizes the significance of documenting design decisions for traceability and understanding their implications on business requirements.

1. Design Decisions
Afaq Mansoor Khan
Teacher: Mr. Ahsan Ashfaq
Subject: Software Architecture & Design

2. Architectural Design Decisions
“In software engineering and software architecture design, design
decisions address architecturally significant requirements; they are
perceived as hard to make and/or costly to change.”
It is called also architecture strategies and tactics.

3. Design as a series of Decisions
A designer is faced with a series of design issues
1. These are sub-problems of the overall design problem.
2. Each issue normally has several alternative solutions(or design options)
3. The designer makes a design decision to resolve each issue.
The designer makes a design decision to resolve each issue.
This process involves choosing the best option from among the alternatives.

5. Taking Decisions
To take each design decision, the software engineer uses:
→the “current” knowledge
1. the requirements
2. the design as created so far
→and “past” knowledge
1. the technology available
2. what has worked well in the past
3. software design principles and “best practices”

6. Types of Design Decisions
There are two types of undocumented design decisions:
● The design decision is implicit: this can happen mainly because the architect
is unaware of the decision. It happens when designers or developers break
the architecture or use it in an unanticipated way without communicating the
issue to software architects.
● The design decision is explicit but undocumented: the architect takes the
decision for some reasons and due to the lack of governance they are not
documented and there is no traceability why this decision has been taken.

7. Notations and Tools

8. QOC
Questions, Options, Criteria
1. Questions: key design issues
2. Options: possible answers
3. Criteria: assess and compare the options

10. Tools
Archium: A meta-model and tool developed my Anton Jansen et al
ADDSS: a web based tool developed by Rafael Capilla et al
AREL: a rationale based model developed by Antony Tang et al
DAMSAK: Data Model for Software Architecture Knowledge developed by Babar
et al developed by Babar et al
PAKME : a tool that supports DAMSAK
SEURAT: Software Engineering using Rationale, which integrates tools for
rationale capture, visualization, and use into a standard software engineering
environment

11. Why are the architecture decisions important?
1) We can consider it as a way of thinking to summarize why we needed this
decision and why we decided this change to happen and chose this option for
it.
2) It will provide a way of traceability of these decisions as we know why we took
them, what are the concerns and business requirements related to these
decisions, who are the contributors to these decisions.

12. References
1) https://melsatar.blog/2017/04/29/architectural-design-decisions/
2) https://www.infoq.com/articles/sustainable-architectural-design-decisions/
3) https://medium.com/omarelgabrys-blog/design-decisions-ac852e28270e
4) https://stal.blogspot.com/2010/03/implicit-versus-explicit.html