[ISAQB] Chapter 2. SW Architecture fundamentals

 

 

 

<목차>

 

 

🟡 2.1 Magic Rectangle

 

✅ QTEF(Quality, Time, Effort, Functionality)

 

 

 

- Effort: within budget

- Time: on time

- Functionality and Quality: desired quality

 

 

 

 

 

🟡 2.2 Software-intensive systems and software architectures

 

✅ 2.2.1 Software-intensive system

 

- System: A collection of components

- Software: Computer programs, procedures, and possibly associated documentation and data pertaining to the operation of a computer system

- Software-intensive system: A collection of building blocks that are organized in such a way that they together accomplish the purpose of the system.

 

 

✅ 2.2.2 "3 types" of software-intensive systems

 

🔸 3 types of software

1) Application software - computer user: web browser

2) Supporting software - programmer: insurance system

3) System software - programmer: web browser

 

"SW can be categorized depends on the viewer's perception!!!"

 

 

 

 

 

🔸 3 types of software-intensive systems

1) Information system: management and processing of information

                                     nF - data management and associated transaction control

2) Embedded system:  embedded into physical objects.(IPA)

                                    nF - scheduling of the active process or communication load on the network

3) Mobile system: autonomous functionality.(smartphone)

                              nF - striking a balance between the required hight quality but graphical user interface

 

 

 

 

 

 

✅ 2.2.3 Good SW Architecture

 

1) Easy to change existing functionality

2) Introduce new functionality without endangering the quality characteristics of the existing SW

3) Hierarchical decomposition of the system into subsystems or building blocks

 

 

Important goals of software architecture
1) Achieve quality requirements in a comprehensible way
2) Enable a basic understanding of structures and concepts for the development team and other stakeholders
3) The most important qualities for the system are known
4) Organizational constraints are known

 

 

 

 

 

🟡 2.3 Fundamental software architecture concepts

 

 

What is SW Architecture?
1. defines the framework for future changes
2. the sum of all the decisions you have taken during development

 

 

 

✅ 2.3.1 Interface

 

🔸 4 types of Interface

 

1. Use of interface should be easy to learn

2. Write client code for the interface, that is reaonably easy to understand

3. Interface specifications should contain functional and non-functional aspects

 

 

 

[Meaning]

     - "Connect building blocks"

     - Access point to the system or building blocks

     - Describe the characteristics of the access point

 

 

[Types]

 

 

1) Standard interface: defined by external third party / both providing and requesting building blocks comply with it

"제 3자"

 

2) Provided interface: Apart from the standard interface / import / commonly used

"구현된 인터페이스"

 

3) Required(requested) interface: incorporate building blocks with specific functionality into a program structure / export

"제공 받아야 하는 인터페이스"

 

4) Independent interface: define their own interface / increase decoupling of the building blocks

"독립된 인터페이스" - KSP

 

 

 

 

✅ 2.3.2 Building block

 

Components = special form of building blocks

 

 

🔸 3 characteristics of Building block

 

 

[Meaning]

    - Reusable component

    - Abstarct component elements of SW architecture

    - "Abstraction of source code"

 

 

 

 

[Characteristics]

 

 

 

1) Provided and Required interfaces

     * Provided interface: Class에 의해서 구현 되어야 하는 것

     * Required interface: 다른 Class에 의한 구현을 필요로 하는 것

 

  

출처: https://velog.io/@jungmyeong96/UML-%EB%8B%A4%EC%9D%B4%EC%96%B4%EA%B7%B8%EB%9E%A8-%EC%9E%91%EC%84%B1%EB%B2%95

 

 

2) Encapsulation and Interchangeability: 연관된 것들을 묶기(외부에 감춤) / 호환성

 

3) Configuration and hierachical (de)composition: Building block들 사이의 관계

 

 

 

🔸 3 views of Building block

 

1) Black box view

: Only see the interface provided and required by building block

                              ex) using in UML Component diagram

 

 

Black box description: public interface, responsibility of the building block

 

 

 

2) Gray box view

: Show technical interfaces are required by building block

                             ex) using in UML Distribution diagram

 

 

3) White box view

: Provides a view of the internal details of the building block ---> decomposition into the configuration of the sub-building blocks or a different type of implementation

                              ex) using in UML Composite structure diagram

 

White box description: internal structure of the building block, specification of the implementation details

 

 

Black box view of building block A
ㄴ decomposed in White box view of building block B1, B2, B3
---------------- b1, b2, b3 == NOT building block, BUT placeholder --------------------

 

===> Building block has an interface to another building block in the gray box

 

 

 

 

✅ 2.3.3 Concepts for describing SW architectures

 

 

• Architectural view = Functional architecture level
• View = Static view & Dynamic view
• Diagram = Static diagram & Dynamic diagram
• Free text = Documenting and Understanding "rationale"

 

 

🔸 view VS viewpoint

• View: 시스템을 바라보는 관점
• Viewpoint: 그 관점에서 시스템을 구성하는 요소와 그 요소들 간의 관계를 표현

"Stakeholder has a different view depending on 'View point'"

 

 

 

 

✅ 2.3.4 Architecture description and architectural levels

 

🔸 Architecture description

 

 

• Architectural style: Central metaphor of the system (e.g. structured 3 layers architecture using a MVC)
• Technical infrastructure: Network profiles of the ARCH (e.g. have application container and a relational database)
• Functional architecture level: Appropriate building blocks and their relationships are designed for the implementation of "functional requirements" (e.g. design can be for a generic insurance product model)
• Technical architectural level: cross-disciplinary solution building blocks are designed and documented based on "Non-functional requirements" (e.g. versioning of all functional entities may be necessary)

 

 

🔸 Interactions between software architecture and environment

 

 

• Project environment and project management: a variety of constraints and project objectives. "budget and development approach"
• Prodcut management and Requirements Engineering: F-req & nF-req, quality objectives, and constraints on the system
• Execution platform and operation: new system usage -> take into account during architecture design
• Tool environment and development: appropriate tool & development organization. "Programming languages, frameworks, technologies" and extension of test infrastructure

 

 

 

 

✅ 2.3.5 "8 quality characteristics" of SW architecture

FURPS + MPC

 

 

[3 factors which can influence the design of a software architecture]

"Political" & "Oranizational" & "Technical"

 

 

 

🟡 2.4 View of Software architecture design

 

 

🔸 Twin peaks model

 

 

---> 요구사항 분석이 완료된 이후 아키텍처의 설계를 진행하는 방식에서 벗어나, 아키텍처 설계와 요구사항 분석이라는 개발의 '두 봉우리'를 동시에 오가면서 주기를 반복해나가는 방식. 이 과정을 통해 아키텍처와 요구사항을 모두 구체화해나가게 됨.

"초기 아키텍처 설계 시, 현재 요구사항을 만족하는 상용화된 제품들을 확인하고 구체화 함에 따라 그 범위를 지속적으로 줄여갈 수 있음"

 

 

 

🔸 "4 activities of SW architecture design

"Common understanding" is important for structuring SW architecture

 

 

 

"Analysis and management of requirements"

1. Analysis of requirements and constraints

• Analyze the objectives, constraints, F-req and nF-req
• Analysis of quality, flexibility, susceptibility to change
• Initial understanding of the architecture style and the technical infrastructure
• Central architectural metaphor of the system

 

"Hanling of architecture models & documentation"

2. Development of architecture views and technical concepts

• View-based description of the different architecture level
• Break down the F-req and nF-req (functional architecture level)
• Document appropriate cross-cutting solution building blocks (technical architecture level)

 

"undergo Quality assurance"

3. Evaluation of architecture and design decisions

• Derivation of specific scenarios from the requirements to ensure the quality of the resulting architecture

*** Architectural / Design decision ***
1. Architectural decisions can impact the structure of the building block or components
2. Architectural decisions can have interdependencies between each other
3. Tradeoffs between conflicting quality requirements should be explicit decisions
반드시 문서로 작성되어야 하는 것은 아님!!!

 

"Communication"

4. Implementation support and review

• Communication of SW architecture
• Architecture can be explained to the customer with a different level of detail than to the developer
• Implementation: discuss open issues, potential for improvement, faults and errors, approaches for further development

 

 

 

🔸 Overview of SW architecture design

 

Top-down / Bottom-up 모두 가능

 

 

 

 

 

 

 

🟡 2.5 Role of SW architect

 

1) Communication and discussion platform

• Present feasibility of requirements to stakeholders
  • explicit and concrete quality requirements
  • check requirements for technological feasibility
• Identify ways of integrating existing solutions and systems
  • Help to identify new business opportunities based on architect's technology know-how
• Align the requirements to the existing system architecture and hardware
• Advise the PM on project an iteration planning
• Support risk analysis and mitigation(완화, 경감)

 

2) Design and implementation plan

• Central point of contact for the system's developers
• Define the system's building blocks and interaction patterns
• Encourage the integration of new technologies and innovative solution approaches 
• Provide development specification and explain architecture and carries out code reviews
• Support testers: assist in the definition of test sequences and dependencies

 

3) Required product qualities should drive SW architect's architctural decisions

 

 

 

 

 

Reference

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

 

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

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

 

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

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

Downloads – iSAQB – International Software Architecture Qualification Board

https://isqi.org/en/