Toetsvragen pool 2 tot 22 Flashcards
Name three concerns per viewpoint development view and physical view; pose the concerns as questions, starting with I want to know…
Development view:
code is organized into modules and components
which components are dependent on each other and how they interact.
manage version control and code branching strategies
Physical view:
how the system is deployed”
what hardware is needed to meet requirements.”
how the system can handle failures”
Look at the figure showing Kruchten’s 4+1 view model.
For each view, describe typical stakeholders (at least 1) and their concerns (at least 1).
Logical view End users: Concern Functionality
Development view: Developers Concern Software Management
Physical View: System engineers: Concern: Topology
Process view Integrators: Concern: Performance/Scalability
Name three concerns per viewpoint process view and physical view; pose the concerns as questions, starting with I want to know…
The process view
different parts of the system communicate with each other.”
how the system handles multiple tasks running at the same time.”
what happens if one part of the system fails.”
Physical View
how the system is deployed”
what hardware is needed to meet requirements.”
how the system can handle failures”
Explain the concepts of components and containers, which
are two of the key abstractions used in the C4 framework. Give two examples of typical containers
in C4.
Containers are deployable parts of the system that interact with each other (like applications, services, or databases).
Components are the individual building blocks within each container, responsible for specific functions or services within that container.
web application and database
C4:Name the four types of diagrams and
describe the content, scope and target audience for each diagram.
Diagram : Context Diagram, Content: Shows system and external entities. Scope: Entire system in its environment. Target Audience: Non-technical stakeholders
Diagram: Container Diagram, Content:Breaks down system into containers, Scope: Internal organization of the system, Target Audience: Developers
Diagram: Component diagram, Content: Details components within a container. Scope:Single container’s internal structure, Target Audience: Developers
Diagram: Class diagram, Content: Lowest-level code structure, Scope:Specific classes and methods, target audience: Developers
what is is missing in C4 compared to 4+1?
Stakeholder Views
4+1 View Model: This framework emphasizes stakeholder concerns through its various views (logical, development, process, physical, and use cases). Each view is designed to address specific stakeholder needs and perspectives, ensuring that different concerns are represented and documented.
C4 Model: While C4 does consider different levels of abstraction (context, container, component, and code), it does not explicitly map views to stakeholder concerns. Thus, the granularity of addressing stakeholder requirements is not as pronounced as in the 4+1 model
Name all four core diagram names and describe how they fit into the standard iso
(2 points). Use at least four different elements/parts of the standard in your answer (for every
correct usage 1 point).
Context diagram:Stakeholders, also involves understanding the Stakeholders and their interactions with the system
Container diagram:Architecture View The Container diagram provides an Architecture View by breaking down the system into major containers (applications, databases, etc.) and how they interact.
Component diagram:Architecture Viewpoint: It reflects an Architecture Viewpoint as it provides a way of looking at the system’s internal design from the perspective of developers or other stakeholders interested in implementation details.
class diagram:Architecture View: It serves as another Architecture View focusing on a specific aspect of the architecture—namely, the actual code structure and its organization.
Describe three or more advantages of explicitly describing architecture decisions as part of a
software architecture documentation.
Improved Communication and Knowledge Sharing:
Explicitly documenting architecture decisions helps convey the rationale behind decisions to team members, stakeholders, and future maintainers. This shared understanding reduces misunderstandings and helps align the team on the architecture’s goals and constraints.
Better Decision Traceability and Historical Context:
Architecture decisions provide a record of why and how key choices were made, creating a traceable history of the decision-making process. This context is invaluable when revisiting or reassessing decisions in light of new requirements, technologies, or constraints
Risk Management and Justification for Stakeholders:
Documenting architecture decisions helps identify and address risks early, as it requires architects to articulate the pros, cons, and risk mitigations associated with each decision.
In their article Architecture Decisions: Demystifying Architecture, Tyree and Akerman describe a
number of concerns that traditional architectural approaches fall short in. According to the authors,
architecture decision documentation can remedy these shortcomings. Describe three of those
shortcomings.
- Lack of Traceability
Traditional architectural approaches often lack adequate traceability between decisions and business objectives, leading to confusion about the rationale behind those choices.
2 Inflexibility to Change
Static architectural documents quickly become outdated, making it difficult to implement adjustments as requirements evolve.
- Communication Gaps
Communication between team members and stakeholders is often insufficient, resulting in misunderstandings and misalignment of expectations.
What is meant with the term forces in the context of architecture decision docu-
mentation? Explain the meaning of the term and give at least two examples of typical forces.
the term forces refers to the various influencing factors or pressures that impact architectural decisions.Forces are essentially the drivers that necessitate certain decisions over others, influencing trade-offs and compromises made during the architectural design process.
Technical Constraints:
These forces may include limitations imposed by the technology stack, such as performance bottlenecks, compatibility with existing systems, or specific requirements of programming languages and frameworks. For instance, if a system must integrate with legacy software, the choice of new technologies may be limited to those that are compatible with the legacy systems.
Regulatory Requirements:
Legal and compliance obligations can also act as significant forces. For example, if a system handles sensitive data, it may need to adhere to regulations like GDPR or HIPAA, which would necessitate architectural decisions around data storage, encryption, and access controls.
