[ISAQB] Chapter 4. Description and Communication of Software Architectures

 

 

 

 

<목차>

 

 

 

🟡 4.1 CoCoME system

 

CoCoME: Common Component Main Example

 

 

 

 

 

 

🟡 4.2 Views and templates

 

✅ 4.2.1 "4+1 model"

 

 

• Context view: design the system as a black box
• Building block view: functional and technical SW building block and their relationship
• Runtime view: main sequence between the building blocks
• Deployment view(= infrastructure view): mapping of the software to the physical technical infrastructure
• Data view: detailed description of the database structures of a software system
• "Big Picture": high-level system architecture for communication with management
• Mask(or sequence) view: website screen sequence diagram

 

 

 

✅ 4.2.2 UML structure diagram and UML behavior diagram

 

 

 

🔸 UML structure diagram

 

     1) UML Class diagram: 클래스의 정적인 구조 및 클래스들 사이의 관계를 표현한 다이어그램 / "시스템의 구조 및 관계"

 

 

    2) UML Component diagram: building block의 큰 그림을 보여주고, 컴포넌트를 사용하는 다이어그램 /  "시스템의 overview"

 

 

 

 

🔸 UML behavior diagram

 

    1) UML Activity diagram: 시스템 구성 요소들의 흐름을 보여주는 다이어그램 /  "시스템 구성요소의 효능"

 

 

 

 

    2) UML Sequence diagram: 시스템 구성 요소들 간의 상호작용을 보여주는 다이어그램 /  "상호작용"

 

 

 

 

 

 

✅ 4.2.3 High level structure

 

🔸 Template-type view description

 

1) Brief description: 'what is involved in this specific case'

 

2) Diagrams: graphical representation

 

예시

 

 

3) Element catalog: property, relationship, interface, behavior of elements

 

예시

 

 

4) Variability: changeability and flexibility

 

 

5) Background information: justification and reference and design decision

 

예시

 

 

 

 

✅ 4.2.4 "4 types" of Views

 

🔸 Context view

: Environment of a system and the relationships and connections with this environment

  / All relevant aspects of the interfaces be specified in the context view

모든 View의 근본이 되는 view, 소프트웨어 시스템이 black box 상태로 다른 것들과 상호작용 할 수 있도록 해줌

"Interfaces to adjacent systems"

 

 

     [Stakeholders]

 

 

 

     [Elements]

 

• Functional: UML component diagram / UML composite structure diagram / "black box at the center"
  • static: architecture, design, development
  • dynamic: test & operation
• Technical: UML component diagram(using UML node) / UML package symbol / Non-UML network symbol(e.g. Visio) / "boxes and arrows"---> physical channel between system and its environment / functional context에 비해 추가적인 element를 가짐

 

 

     [Examples]

 

 

 

🔸 Building block view

: show static structure of a software system & relationship between building blocks

     

     [Contents]

abstarction of source code

 

     [Stakeholder]

 

       [Elements]

 

 

     [Examples]

 

 

 

 

🔸 Runtime view

: interactions between elements of the software system at runtime

"Focus on important elements of the system and examples"

 

     [Stakeholder]

 

      [Elements]

          - UML Activity, Communication, Sequence diagram

          - Traditional flow diagram

          - (pseudo) code

          -  Informal verbal sequence description

          - BPMN(Business Process Model and Notation)      

 

 

     [Examples]

     

     - UML Sequence diagram

 

 

 

      - UML Communication diagram

 

 

 

🔸 Deployment/Infrastructure view

: Mapping of the software system to 'reality'

building block view의 요소들이 배치됨 / real software operating environment

 

     [Stakeholder]

 

     [Elements]

 

 

     [Examples]

Node, Component, Channel, DB

 

 

 

✅ 4.2.5 Interdependencies & Hierachical refinement of architecture views

 

🔸 Interdependency

 

1. Design decisions become more comprehensible
2. Impact of changes becomes easily recognizable
3. Dependency between system components are easier to understand

 

 

 

 

🔸 Hierachical refinement

 

context view -> decomposed -> building block view

 

 

     - Black box description

   

 

     - White box description

Design decisions: structure가 생성된 요인, alternatives가 채택되지 않은 요인

 

 

 

 

 

 

🟡 4.3 Technical/Cross-cutting concepts

 

✅ 4.3.1 Technical/cross-cutting concepts: sample dimensions

 

Error handling과 Logging은 independent 관계

 

 

 

✅ 4.3.2 Error handling

"how foreseeable errors can be handled during the operation of the system"

 

1. Identification of error cases
2. Definition of appropriate reactions to errors
3. Minimizing the impact of errors
4. Making diagnosis of error causes easier: 기록 남기기
5. Error provention
6. Definition of the technologies for error handling

 

 

✅ 4.3.3 Security

 

🔸 6 types of security issues

 

1. Authentication(인증): determination of the sender's identity
2. Authorization(허가): granting of user rights
3. Integrity(무결성): recognition of manipulation of protected data
4. Confidentiality(기밀성): not accessed by unauthorized parties
5. Non-repudiation(거절 불가): received messages cannot be denied by the sender
6. Availability: 예기치 않거나 고의로 발생한 시스템 오작동에 대응하기 위한 조치

 

 

 

 

 

🟡 4.4 Architecture and implementation

 

Design -> Build -> Run

 

 

 

[Communicate aspects of software architecture]

• Verbal communication should supplement written documentation
• Feedback to architecture decision can be done both in writing and talking
• There are no general rule and order between verbal and written (둘 중 순서 상관 없음 & 둘 다 사용해도 됨)

 

 

 

🟡 4.5 Document types for Software architecture

 

✅ 4.5.1 Central architecture description

 

core document for a software architecture / contains all information

 

<포함 되어야 할 내용>

1. The architecture's task, objectives(vision), quality requirements and stakeholders: quality requirements help significantly with architecture decisions

2. Technical and organizational conditions and constraints

3. View, decisions, and patterns used

4. Technical concepts

5. Quality evaluations

6. Identified risks

 

---> Architecture decisions record helps to make the decision's context understood & it can be changed

 

ex) Documents, CASE/MDA/UML tools, HTML pages or wikis

 

 

 

✅ 4.5.2 Architecture overview

 

brief, easy-to-read summary of the central architecture description

 

"no longer than 30 pages"

 

 

 

✅ 4.5.3 Document overview

 

directory / index of all architecture-relevant documents and dependencies

 

"show the role in the project"

 

 

 

✅ 4.5.4 Overview presentation

 

summarize the central statements and the business benefit in 10 min

 

"presents the architecture"

 

 

 

✅ 4.5.5 Architecture wallpaper

 

complete overview of a large number of architecture aspects

 

"poster-sized prints"

 

 

 

✅ 4.5.6 Documentation handbook

 

structure and function of the complete project documentation

 

 

 

✅ 4.5.7 Technical Information

 

important information for project developers and testers

 

"development methods, programming guidelines, building and testing of the system"

 

 

 

✅ 4.5.8 Documentation of external interfaces

 

interaction of the overall system with its content

 

"external interfaces become time-consuming problem area"

 

 

 

✅ 4.5.9 Template

 

interface descriptions

 

 

 

 

 

 

 

 

🟡 4.6 Best-practice rules for documentation

 

🔸 8 Rules

1. Write from the readers' perspective: 읽기 쉽게
2. Avoid unnecessary repetition: 불필요한 반복 X
3. Avoid ambiguity: 명확하게 - use formal description language
4. Standardized organizational structure or templates: 특정 template에 맞춰서
5. Justify important decisions in writing: design decision
   • Explict, not implicit
     • make the assumption leading to decision explicit
     • make prerequisites for their decisions explicit
6. Check the documentation's suitability for use: 적합성 체크 - review process
7. Uncluttered diagrams: avoid excessively large diagram - architecture wallpaper는 예외
8. Regular updates: 주기적인 유지보수 필요

 

*** Architecture documentation의 주요 목적 ***
1) To support onboarding of new developers
2) To support the work of distributed teams
3) To assist in future enhacements of the projuct
4) To conform to regulatory or legal constraints (*conform: 집단의 다른 구성원들과 행동[생각]을 같이 하다)

 

 

 

 

 

🟡 4.7 Alternative architecture framework

 

✅ 4.7.1 The 4+1 framework

 

 

• Logical view: consider the software system from a functional perspective (e.g. top-level class diagram)
• Development view: address the system from the development perspective (e.g. UML component diagram)
• Process view: runtime view
• Physical view: address mapping of the software system to specific technical system (e.g. deployment or infrastructure view)

 

 

 

✅ 4.7.2 RM-ODP

 

 

• Enterpise viewpoint: 사용 범위, 운용 목적, rule
• Information viewpoint: data processing 정의 (data model)
• Computational viewpoint: 기능적 요소 및 인터페이스의 형식을 decomposition
• Engineering viewpoint: 매커니즘 & function (interaction of system)
• Technology viewpoint

 

 

 

✅ 4.7.3 SAGA

SAGA(Standards and Architectures for e-Government Applications)

include recommendations for software architectures & orient to RM-ODP
include data and process modeling and technical requirements standards and technology

 

 

 

 

 

 

 

 

 

Reference

Mahbouba Gharbi & Arne Koschel & Andreas Rausch - Software Architecture FundamentalsA Study Guide for the Certified Professional for Software Architecture

 

위 책 내용을 챕터별 중요한 포인트 위주로 정리한 자료입니다.

스스로 공부하기 위한 요점정리 노트이므로 상업적인 사용 목적은 전혀 없음을 알려드립니다:)

 

이 시험에 대한 정보 및 각종 자료는 아래 사이트에서 확인하실 수 있습니다. ⬇⬇⬇

https://www.isaqb.org/downloads/

https://isqi.org/en/