상 구조기반테스트 화이트박스 테스트 = 구조기반 테스트
 
토픽 이름 (상) 구조기반 테스트(Structure-based techniques)
분류 SW > Test > 구조기반 테스트
키워드(암기) 제어구조시험, 루프시험, Coverage, MC/DC
암기법(해당경우) 화제루

 

기출문제

번호 문제 회차
1 소프트웨어 품질의 테스트 방법인 화이트박스 및 블랙박스 테스트의 4가지 검증기준(coverage)을 예를 들어 설명하고, 테스트 자동화 도구의 유형에 대하여 설명하시오. 114.관리.3
2 블랙박스 테스트 (Black Box Test) 와 화이트박스 테스트 (White Box Test) 를 비교 설명하시오. 84.관리.1
3 소프트웨어의 명세 기반 기법 (Specification Based Technique) 테스트와 구조 기반 기법 (Structure Based Technique) 테스트 방법을 나열하고 설명하시오 83.관리.2
4 소프트웨어 Testing 과 관련하여 다음 사항을 설명하시오
1)검증(verification)과 확인(Validation)의 비교 설명
2)블랙박스 시험과 화이트박스 시험의 비교 설명
3)화이트박스 시험의 필요성		 72.응용.2

 

Ⅰ. 프로그램 내부 로직 분석을 통한 테스트 기법, 구조기반 테스트의 개요

  1. 구조기반 테스트(Structure-based Test)의 정의

- 테스트 프로그램 내부 구조를 기반으로 특정 커버리지(Coverage)를 달성하기 위한 테스트 설계 및

케이스를 도출하기 위한 테스트 기법

나. 구조기반 테스트의 특징

특징 설명
White Box Test 프로그램 내부 구조 및 복잡도를 검증, 테스트
Logic Driven 코드 구조의 효율성 및 오류사항 발견

 

II. 구조기반 테스트의 개념도 및 기법

가. 구조기반 테스트의 개념도

- 내부 구조 및 복잡도를 검증하고 테스트하기 위한 White Box Test

 

 

나. 구조기반 테스트의 기법

기법 설명 사례
제어구조 시험
(Control Structure Testing)		 - McCabe에 의해 제안된 대표적 White Box Test 기법
- 프로그램의 처리 흐름을 제어하는 방법 및 수행 제어를 위해 사용되는 문장의 구조		 - 순차형(순차 구조, Sequence형)
- 선택형(분기구조, If Then Else형)
- 반복형(반복구조, Do While형)
루프 시험
(Loop Testing)		 - 프로그램 루프 구조에 국한해서 실시하는 기법
- 루프 시험의 대상 결함 : 초기화 결함, 인덱싱 및 증가의 결함, 루프의 경계선에서 나타나는 경계 오류
- 루프의 유형 : 단순루프, 중첩루프, 연결루프, 비구조적 루프		 - for, while 등
- go to 등

 

 

III. 구조기반 테스트와 명세기반 테스트의 비교

구분 구조기반 테스트 명세기반 테스트
개념도
정의 프로그램 내부 로직을 참조하며
모든 경로를 테스트		 외부 명세로부터 직접 테스트
Data, I/O 위주 테스트
특징 - 구조테스트
- Logic Driven 테스트
- 모듈 테스트		 - 기능테스트
- Data Driven 테스트
- I/O 테스트
적용 단위테스트 위주 대부분의 테스트에 적용
V&V 하위 레벨 테스트 (시험 환경) 상위 레벨 테스트 (사용자 환경)
점검대상 Loop, Decision 결함, 비수행 구문 시작/종료/인터페이스 결함
기법 Loop, 제어구조 테스트 동등 분할, 경계 값 분석, Cause Effect 그래프, 오류 예측 기법
활용분야 알파 테스트 베타 테스트

 

IV. 테스트 커버리지 관계도 및 유형

가. 테스트 커버리지 관계도

- 구문, 결정, 조건, 조건/결정, 변경 조건/결정, 다중 조건 커버리지 관계도 설명

나. 테스트 커버리지 유형

테스트 유형 설명 사례
구문 커버리지
(Statement Coverage)		 - 프로그램을 구성하는 모든 구문들이 최소한 한번은 실행될 수 있는 입력 데이터를 데스트 데이터로 선정
- 프로그램 내 모든 구문의 테스트를 보장		 - 소스코드
If(a>0 or b>0)
call join
- 테스트케이스
a = 3, b = 4
결정 커버리지
(Decision Coverage)		 - 프로그램 내의 전체 결정문이 적어도 한번은 참과 거짓의 결과를 수행하는 테스트 케이스 생성
- 모든 분기문을 테스트 하는 방법
조건 커버리지
(Condition Coverage)		 - 결정 명령문 내의 각 조건이 적어도 한 번은 참과 거짓의 결과가 되도록 수행하는 테스트 케이스
- 모든 조건을 커버하는 방법
조건/결정 커버리지
(Condition/Decision Coverage)		 - 전체 조건식 뿐만 아니라 개별 조건식도 참 한번, 거짓 한번 결과가 되도록 수행하는 테스트 케이스
변경조건/결정 커버리지
(MC/DC)		 - 각 개별 조건식이 다른 개별 조건식에 영향을 받지 않고 전체
조건식에 독립적으로 영향을 주도록 하는 테스트 케이스
다중조건/결정 커버리지(Multiple Condition Coverage) - 결정 포인트 내에 있는 모든 개별식 조건의 모든 조합을 고려한 커버리지
반응형
저작자표시 비영리 변경금지

'정보관리기술사 > 소프트웨어공학' 카테고리의 다른 글

Embedded System Test  (1) 2024.04.09
경험기반 기법  (0) 2024.04.08
Usecase diagram  (0) 2024.04.06
Class diagram  (0) 2024.04.05
UML의 관계(Relationship)  (0) 2024.04.04
상 Usecase diagram 유스케이스 다이어그램(use-case diagram)
[정의] 시스템이 제공하고 있는 기능 및 그와 관련된 외부요소를 사용자의 관점에서 표현하는 동적 다이어그램
[키워드]Actor, Usecase, include, extend, Generalization, Association, Grouping, 직관적 사용자 대화수단		  

 

토픽 이름(상) Usecase diagram
분류 소프트웨어 >UML> Usecase diagram
키워드(암기) Actor, Usecase, include, extend, Generalization, Association, Grouping, 직관적 사용자 대화수단
암기법(해당경우)  

 

기출문제

번호 문제 회차
1 6.아래 시나리오를 기반으로 고객과 점주가 사용하는 주문 시스템에 대한 Use Case Diagram을 작성하시오 가. 고객은 주문 시스템을 통해 가격을 조회하고 주문할 수 있다. 나. 고객은 주문 시스템을 통해 주문 상태를 확인하고 주문을 취소할 수 있다. 다. 점주는 주문 시스템을 통해 주문 활동을 모니터링하고 창고를 관리할 수 있다. 라. 회계 시스템은 주문 시스템과 연동하여 주문이나 취소 처리할 수 있다. 122관3
2 6. UML(Unified Modeling Language)에서 사용하는 행위 다이어그램(behavior diagram) 인 액티비티 다이어그램(activity diagram), 스테이트 다이어그램(state diagram), 그리고 유스케이스 다이어그램(use-case diagram)에 대하여 설명한 후, 레스토랑에서 일어나는 상황을 고객, 웨이터, 요리사, 그리고 계산대 직원을 고려하여 유스케이스 다이어그램으로 표현하시오. 93회_관리_3교시
4 3. 객체지향 모델의 표현 방법인 UML(Unified Modeling Language)을 사용하여 "수강신청 처리"에 대한 시스템을 설계하시오.
반드시 유스케이스 다이어그램(use-case diagram), 시퀀스 다이어그램(sequence diagram), 클래스 다이어그램(class diagram),
액티비티 다이어그램(activity diagram)을 작성하고, 필요시 다른 diagram을 추가 작성하시오.		 86_관리_3
5 1. 시스템이 제공하고 있는 기능 및 그와 관련된 외부요소를 사용자의 관점에서 표현하는 유스케이스 다이어그램에 대하여 아래의 물음에 답하시오.
가. 유스케이스 다이어그램에 대한 설명
나. 예제의 요구사항에 대하여 유스케이스 다이어그램으로 작성		 모의_2018.12_관리_3
6 1. 유스케이스 다이어그램(usecase diagram)에 대하여 설명하시오 모의_2018.07_관리_1

 

 

I. 시스템 기능에 대한 사용자 입장의 표현, 유스케이스 다이어그램의 개요

  가. 유스케이스 다이어그램(Usecase Diagram)의 정의

   - 시스템이 제공하고 있는 기능 및 그와 관련된 외부요소를 사용자의 관점에서 표현하는 동적 다이어그램

    - 시스템 분석가가 사용자와 힘을 합쳐 시스템의 사용 방법을 결정하는데 도움을 주는 도구

 

 나. 유스케이스 다이어그램의 특징

  특징 설명
직관적 사용자의 기능적 요구사항을 정의하는 직관적인 표현
사용과
사용자		 Use Case와 Actor간의 관계를 표현 (Actor는 시스템을 제외한 모든 외부요소로서 시스템을 사용하는 사람 또는 시스템이며, Actor는 Use Case를 수행함)
사용자와 대화 수단 활용 및 내부 기능을 예측할 목적임
분석단계 주로 분석단계에서 수행하여 시스템 개발 전 단계에 영향
기능설명 시스템이 제공하는 기본적인 기능을 설명

 

II. 유스케이스 다이어그램의 구성요소와 표현

가. 유스케이스 다이어그램의 구성요소

분류 구분 설명 표기법
기본
구성		 Usecase - 시스템이 제공해야 하는 서비스.
- Actor가 시스템을 통한 일련의 행위

Actor (행위자) - 사용자가 시스템에 대해 수행하는 역할(role)
- 시스템과 상호작용하는 사람 또는 사물

시스템
(System)		 - 전체시스템의 영역을 표현
- 특별한 의미를 가지지 못함
관계
표현		 연관(Association) Usecase와 Actor의 관계를 표현 (실선)

확장(Extend) 기본 Usecase 수행 시 특별한 조건을 만족할 때 수행하는 Usecase

포함(Include) - 시스템의 기능이 별도의 기능을 포함 (점선)
- Usecase 를 수행할 때 다른 Usecase 가 반드시 수행되는 것

일반화
(Generalization)		 하위 Usecase/Action이 상위 Usecase/Actor에게 기능/역할을 상속 받음

그룹화
(Grouping)		 여러 개의 Usecase를 단순화 하는 방법

 

 

나. Use Case의 구성요소간 관계 표현법

관계 설명 표기법
연관
(Association)		 Use Case와 Actor의 관계를 표현
(실선)
확장
(Extend)		 - Optional behavior. 선택 적인 행동.
- extension method의 stereotype 으로 표시.
포함
(Include)		 - Mandatory behavior. 필수적인 행동.
- extension method의 stereotype 으로 표시.
일반화
(Generalization)		 - 하위 Use Case/Action이 상위 Use Case/Actor에게 기능/역할을 상속 받음
그룹화
(Grouping)		 - 여러 개의 Use Case를 단순화 하는 방법

 

 

III. Use case Diagram 작성 절차와 사례 (레스토랑의 고객, 웨이터, 요리사, 계산대 직원)

  1. Use Case 작성 절차
절차 설명
Actor 식별 - 시스템의 사용자 식별
- 상호작용 하는 타 시스템 식별
Use Case 식별 - 액터가 요구하는 서비스 식별
- 액터가 요구하는 정보 식별
- 액터가 시스템과 상호작용하는 행위를 식별
Relationship 정의 - 액터와 액터간의 관계 분석 및 정의
- 액터와 유스케이스 관계 분석 및 정의
- 유스케이스와 유스케이스 관계 분석 및 정의
Use Case 구조화 - 2개 이상의 유스케이스에 존재하는 공통 서비스 추출
- 추출된 서비스를 유스케이스로 정의
- 추출된 유스케이스를 사용하는 유스케이스 및 사용자 관계 정의

 

  1.  작성 사례
Usecase 명세 Usecase Diagram
1. 웨이터는 고객의 주문을 받는다
2. 웨이터는 주문을 확인한다 (주문상태 포함)
3. 요리사는 주문을 확인한다
4. 웨이터는 음식을 제공한다
5. 계산대 직원은 음식값을 계산 처리한다
반응형
저작자표시 비영리 변경금지

'정보관리기술사 > 소프트웨어공학' 카테고리의 다른 글

경험기반 기법  (0) 2024.04.08
구조기반테스트  (0) 2024.04.07
Class diagram  (0) 2024.04.05
UML의 관계(Relationship)  (0) 2024.04.04
UML / Diagram 전체  (0) 2024.04.03
상 Class diagram 클래스 다이어그램(class diagram)
[정의] 하나 시스템의 Class, 그 클래스 내의의 속성, operations (or methods), and the relationships among objects 간의 관계를 나타내며 객체 지향 시스템 모형화에서 가장 공통적으로 많이 쓰이는 정적 다이어그램
[키워드] 클래스, 속성(Attribute), 연산(Operation), 연관, 집합연관, 복합연관, 의존, 상속, 구현		  
토픽 이름(상) 클래스 다이어그램 (Class Diagram)
분류 SW > UML > Class Diagram
키워드(암기) 클래스, 속성(Attribute), 연산(Operation), 연관, 집합연관, 복합연관, 의존, 상속, 구현
암기법(해당경우)  

 

기출문제

번호 문제 회차
1 6.아래 내용을 반영한 클래스 다이어그램(Class Diagram)을 작성하시오 가. 훈련교사(Trainer)는 하나 이상의 여러 종목(Pragram)을 훈련시킬 수 있다. 나. 각 종목(Prgramm)은 훈련시간표 상 슬롯(Slot)에 훈련시간(Time)과 훈련실(Room)이 할당되어 있다. (클래스) (속성) Trainer id, name Program number, name Room number, name Time day, hour 122관4
2 객체지향 모델의 표현 방법인 UML(Unified Modeling Language)을 사용하여 "수강신청 처리"에 대한 시스템을 설계하시오.
반드시 유스케이스 다이어그램(use-case diagram), 시퀀스 다이어그램(sequence diagram), 클래스 다이어그램(class diagram), 액티비티 다이어그램(activity diagram)을 작성하고, 필요시 다른 diagram을 추가 작성하시오.		 86.정보관리.3
3 객체지향 모델 표현 UML(Unified Modeling Language)의 특징을 설명하고, "온라인 상품 주문"에 대한 시스템을 설계하기 위해 유스케이스 다이어그램(usecase diagram), 시퀀스 다이어그램(sequence diagram), 클래스 다이어그램(class diagram)을 작성하시오. 모의_2016.04.관리.4
4 3. 모두 60개의 객실을 보유하고 있는 호텔의 객실 예약 시스템을 구축하고자 한다. 호텔 객실 예약 시스템은 담당 직원에 의해 운용된다. 담당 직원은 객실 예약 시스템을 통해 객실을 검색하고 예약할 수 있으며, 예약을 취소할 수 있어야 한다. 객실 예약시스템은 사용이 쉬워야하며 기존의 시스템(하드웨어)를 이용하여 구축할 수 있어야 한다.
가) 기능적인 요구사항을 Use Case diagram으로 기술하시오.
나) 위의 요구사항을 만족하는 시스템의 정적 구조를 Class diagram을 사용하여 기술하시오.		 모의_2010.01.관리.4.3

 

I. 객체타입을 정의하고 정적인 관계를 표현하는, 클래스 다이어그램의 개요

- 시스템을 구성하는 객체의 타입을 정의하고, 그 타입들 간의 존재하는 관계를 표현하는 정적 다이어그램

- Class, Interface, Collaboration 간의 관계를 나타내며 객체 지향 시스템 모형화에서 가장 공통적으로 많이 쓰이는 다이어그램

II. 클래스 다이어그램의 구성도 및 구성요소

가. 클래스 다이어그램의 구성도

 

 

나. 클래스 다이어그램(Class Diagram)의 구성요소

-구성(이름,속성,기능)

 

-접근제어자

 

-관계

 

-연관의 다중성 표현 (선에 아무런 숫자없으면 1:1 관계)

III. 클래스 다이어그램의 관계 표현

관계 유형 설명 표기법
연관관계
(Association Relationship)		 - 두 클래스간 서로 어떠한 연관을 가지고 있는 의미
1 : 1개  0..1 : 0개 또는 1개
* : 다수 1..* : 1개 또는 다수
집합연관관계
(Aggregation Relationship)		 - 클래스와 클래스간의 부분과 전체의 관계를 의미
- UML 2.0에서는 사용하지 않음
의존관계
(Dependency Relationship)		 한 클래스의 변화가 다른 클래스에 영향을 미치는 관계
복합연관관계
(Composition Relationship)		 집합연관관계와 같이 부분과 전체 관계이나, 전체클래스 소멸시 부분클래스도 소멸하는 관계
상속관계
(Inheritance)		 Class 간 상속관계 (‘is a’ 관계) 객체지향의 상속관계를 의미하고, 일반화(Generation)를 의미한다.
인터페이스 인터페이스와 그 인터페이스를 구현한 클래스 사이의 관계를 의미
(실체화: 하나의 객체가 다른 객체에 의해, 오퍼레이션을 하도록 지정관계)
직접 연관(Direct Association) Association과 Directed Association의 차이는 화살표가 의미하는 navigability(방향성)인데 이것에 따라 참조 하는 쪽과 참조 당하는 쪽을 구분
반응형
저작자표시 비영리 변경금지

'정보관리기술사 > 소프트웨어공학' 카테고리의 다른 글

구조기반테스트  (0) 2024.04.07
Usecase diagram  (0) 2024.04.06
UML의 관계(Relationship)  (0) 2024.04.04
UML / Diagram 전체  (0) 2024.04.03
MSA  (0) 2024.04.02

연관관계, 의존관계, 일반화(Generalization), 실체화(Realization)

중 UML의 관계(Relationship) 의존관계, 연관관계, 일반화(Generalization), 실체화(Realization)
연의GR
토픽 이름(상) 관계(Relationship)
분류 소프트웨어 >UML> Usecase diagram
키워드(암기) 연관관계, 의존관계, 일반화(Generalization), 실체화(Realization)
암기법(해당경우) 연의 GR

 

기출문제

번호 문제 회차
1 6.아래 시나리오를 기반으로 고객과 점주가 사용하는 주문 시스템에 대한 Use Case Diagram을 작성하시오 가. 고객은 주문 시스템을 통해 가격을 조회하고 주문할 수 있다. 나. 고객은 주문 시스템을 통해 주문 상태를 확인하고 주문을 취소할 수 있다. 다. 점주는 주문 시스템을 통해 주문 활동을 모니터링하고 창고를 관리할 수 있다. 라. 회계 시스템은 주문 시스템과 연동하여 주문이나 취소 처리할 수 있다. 122관3
2 6. UML(Unified Modeling Language)에서 사용하는 행위 다이어그램(behavior diagram) 인 액티비티 다이어그램(activity diagram), 스테이트 다이어그램(state diagram), 그리고 유스케이스 다이어그램(use-case diagram)에 대하여 설명한 후, 레스토랑에서 일어나는 상황을 고객, 웨이터, 요리사, 그리고 계산대 직원을 고려하여 유스케이스 다이어그램으로 표현하시오. 93회_관리_3교시
4 3. 객체지향 모델의 표현 방법인 UML(Unified Modeling Language)을 사용하여 "수강신청 처리"에 대한 시스템을 설계하시오.
반드시 유스케이스 다이어그램(use-case diagram), 시퀀스 다이어그램(sequence diagram), 클래스 다이어그램(class diagram),
액티비티 다이어그램(activity diagram)을 작성하고, 필요시 다른 diagram을 추가 작성하시오.		 86_관리_3
5 1. 시스템이 제공하고 있는 기능 및 그와 관련된 외부요소를 사용자의 관점에서 표현하는 유스케이스 다이어그램에 대하여 아래의 물음에 답하시오.
가. 유스케이스 다이어그램에 대한 설명
나. 예제의 요구사항에 대하여 유스케이스 다이어그램으로 작성		 모의_2018.12_관리_3
6 1. 유스케이스 다이어그램(usecase diagram)에 대하여 설명하시오 모의_2018.07_관리_1

 

 

I. UML의 관계(Relationship) – ‘연의 GR’ 이라고 암기한다. ★

- UML에는 4개의 관계가 있다. 연관관계, 의존관계, 일반화(Generalization), 실체화(Realization) 이다.

 

 

 

 

반응형
저작자표시 비영리 변경금지

'정보관리기술사 > 소프트웨어공학' 카테고리의 다른 글

Usecase diagram  (0) 2024.04.06
Class diagram  (0) 2024.04.05
UML / Diagram 전체  (0) 2024.04.03
MSA  (0) 2024.04.02
SW Architecture 평가  (0) 2024.04.01
상 UML / Diagram 전체 전체 다이어그램 구분 정리
[구조 기반] 클래스(Class) Diagram, 컴포넌트(Component) Diagram, 객체(Object) Diagram, 배치(Deployment) Diagram, Composite Structure  Diagram, Package
Diagram, Profile Diagram
[ 행위 기반 다이어 그램] 활동(Activity), 유즈케이스(Use Case), 상태(State) 상호작용 다이어그램(Interaction Diagram), 순차(Sequence)다이어그램, Communication
Diagram, 상호작용 개요다이어그램(Interaction Overview Diagram), Timing Diagram		 itpe 특강 볼것  
토픽 이름(상) UML / Diagram
분류 소프트웨어 >UML> Diagram
키워드(암기) [구조 기반] 클래스(Class) Diagram, 컴포넌트(Component) Diagram, 객체(Object) Diagram, 배치(Deployment) Diagram, Composite Structure  Diagram, Package
Diagram, Profile Diagram
[ 행위 기반 다이어 그램] 활동(Activity), 유즈케이스(Use Case), 상태(State) 상호작용 다이어그램(Interaction Diagram), 순차(Sequence)다이어그램, Communication
Diagram, 상호작용 개요다이어그램(Interaction Overview Diagram), Timing Diagram
암기법(해당경우)  

기출문제

번호 문제 회차
1 6.아래 시나리오를 기반으로 고객과 점주가 사용하는 주문 시스템에 대한 Use Case Diagram을 작성하시오 가. 고객은 주문 시스템을 통해 가격을 조회하고 주문할 수 있다. 나. 고객은 주문 시스템을 통해 주문 상태를 확인하고 주문을 취소할 수 있다. 다. 점주는 주문 시스템을 통해 주문 활동을 모니터링하고 창고를 관리할 수 있다. 라. 회계 시스템은 주문 시스템과 연동하여 주문이나 취소 처리할 수 있다. 122관3
2 6. UML(Unified Modeling Language)에서 사용하는 행위 다이어그램(behavior diagram) 인 액티비티 다이어그램(activity diagram), 스테이트 다이어그램(state diagram), 그리고 유스케이스 다이어그램(use-case diagram)에 대하여 설명한 후, 레스토랑에서 일어나는 상황을 고객, 웨이터, 요리사, 그리고 계산대 직원을 고려하여 유스케이스 다이어그램으로 표현하시오. 93회_관리_3교시
4 3. 객체지향 모델의 표현 방법인 UML(Unified Modeling Language)을 사용하여 "수강신청 처리"에 대한 시스템을 설계하시오.
반드시 유스케이스 다이어그램(use-case diagram), 시퀀스 다이어그램(sequence diagram), 클래스 다이어그램(class diagram),
액티비티 다이어그램(activity diagram)을 작성하고, 필요시 다른 diagram을 추가 작성하시오.		 86_관리_3
5 1. 시스템이 제공하고 있는 기능 및 그와 관련된 외부요소를 사용자의 관점에서 표현하는 유스케이스 다이어그램에 대하여 아래의 물음에 답하시오.
가. 유스케이스 다이어그램에 대한 설명
나. 예제의 요구사항에 대하여 유스케이스 다이어그램으로 작성		 모의_2018.12_관리_3
6 1. 유스케이스 다이어그램(usecase diagram)에 대하여 설명하시오 모의_2018.07_관리_1

 

 

I. 객체지향 모델링 기술과 방법론의 표준, UML의 개요 – 그래픽 형태를 통한 객체지향 설계 설명 도구

   가. UML(Unified Modeling Language)의 정의

      - 객체 지향 분석/설계가 S/W공학의 새로운 추세로 자리매김함에 따라 관련된 방법론을 표준화할

         필요성을 느끼고 OMG(Object Management Group – UML, MDA를 제정한 협회)에서 객체

        모델링 기술과 방법론을 표준화 한 것으로 단어자체가 의미하는 언어가 아니고 모델링을

        위한 Notation을 말함 

 

   나. UML의 등장 배경 및 필요성

      - 객체지향 모델링을 위해 학자들 마다 중복되고 일부 다른 방식으로 표현,

      - 보다 체계적인 모델링 방법을 표준화하기 위해 3명의 학자가 주장하는 표기법의 통일이 필요하게 됨

      - 객체지향 시스템 개발 전 과정(Life Cycle)에서 개발자와 사용자간에 표준화된 의사소통 방식 필요

      - 자기 자신, 팀 동료, 고객들과의 의사소통 – 자신의 이해가 다른 사람과 일치하는지 확인하기 위한

        방법(1994년, 부치, 럼바, 야콥슨 연구시작 -> 1997년 발표)

 

가. 정적 다이어그램

구분 분  류 내  용
정적
모델링
(정적인부분/
구조모델링)		 클래스(Class) Diagram - 시스템 내 클래스들의 정적 구조를 표현
- 클래스는 객체들의 집합으로 속성(Attribute)과 동작(Behavior)으로 구성됨.

컴포넌트(Component)
Diagram		 - 코드 컴포넌트(Code component)에 바탕을 둔 코드의 물리적 구조를 표현
- 컴포넌트(component)는 논리적 클래스 혹은 클래스 자신의 구현에 대한 정보를 포함함.
- 실질적인 프로그래밍 작업에 사용함.

객체(Object) Diagram - 클래스의 여러 Object 인스턴스(Instance)를 나타내는 대신에 실제 클래스를 사용함.
- 클래스 다이어그램에서 2가지 예외를 제외하고 동일 표기법을 사용함.
- Object 이름에 밑줄 표시를 하며, 관계 있는 모든 인스턴스를 표현함.

배치
(Deployment)
Diagram		 - 시스템 하드웨어와 소프트웨어간의 물리적 구조를 표현하며, 실질적인 컴퓨터와
  Device간의 관계를 표현하는데 이용함.
  컴포넌트(Component) 사이의 종속성을 표현함.

Composite
Structure
Diagram		 - 분류자의 복합 구조를 표현하는 다이어그램
- port, part, connector, Collaboration으로 분류자 내부 구조 표현

Package
Diagram		 - 패키지들과 패키지 내부의 요소를 표현
- 클래스, 인터페이스 등 분류자 등을 그룹화하여 보여 주기 위함

Profile
Diagram		 profile diagrams are: profile, metaclass, stereotype, extension, reference, profile application.(우리가 프로파일을 말할 때와 같은 의미로 사용)

 

나. 동적다이어그램

구분 분  류 내  용
동적
모델링
(행위 다이어그램)		 활동
(Activity)		 - 행위(Activity)의 순서적 흐름을 표시함.
- 연산자로 수행된 활동 상황(Activity)을 설명키 위해 사용함.

유즈케이스
(Use Case)		 - 외부 행위자(Actor)와 시스템이 제공하는 여러 개의 Use Case(시스템을 사용
하는 다양한 경우에 연결하여, Use Case 다이어그램은 유즈케이스 뷰를 다룬다.

상태(State) - 클래스의 객체가 가질 수 있는 모든 가능한 상태를 나타냄.

상호작용 다이어그램(Interaction Diagram) 4개의 다이어그램을 통합한 그룹 /*시퀀스, 커, 인, 타 */
- 행동 다이어그램의 서브(하위) 집합인 상호 작용 다이어그램은 모델링되는 시스템에서 사물 간의 제어 및 데이터의 흐름을 강조함.

순차
(Sequence)
다이어그램		 - 여러 객체 사이에 동적인 협력 사항을 표현함.
- 오브젝트(Object) 사이에 메시지를 보내는 순서를 보여주기 위해 사용함.
- 수직선상의 여러 object로 구성되어 시간 혹은 순서가 강조되어야 할     경우 이용함.

Communication
Diagram		 - UML1.x의 Collaboration Diagram에서 변경됨
- A communication diagram is an extension of object diagram that shows the objects along with the messages that travel from one to another.
(Example – Hotel Reservation)

상호작용 개요
다이어그램(Interaction Overview Diagram) 		액티비티 다이어그램과 시퀀스 다이어그램의 혼합된 다이어그램 ★★★
1) 활동 다이어그램과 유사 -> 차이점: 상호작용 개요 다이어그램의 경우는 각 개별 활동이 중첩된 상호 작용 다이어그램으로 포함할 수 있는 특징이 있다.
   -> 복잡한 시나리오를 분해하는데에 유리함

Timing Diagram - 시간의 흐름에 따른 상태를 표현
- 가로 축 시간 표현, 세로 축에 상태로 하여 상태 변화를 나타냄
반응형
저작자표시 비영리 변경금지

'정보관리기술사 > 소프트웨어공학' 카테고리의 다른 글

Class diagram  (0) 2024.04.05
UML의 관계(Relationship)  (0) 2024.04.04
MSA  (0) 2024.04.02
SW Architecture 평가  (0) 2024.04.01
ISO/IEC/IEEE 42010  (1) 2024.03.31
MSA 상 MSA [정의] 대규모 분산 웹 환경에서 응용 소프트웨어를 독립적으로 배치 가능한 서비스 조합으로
설계하는 아키텍쳐
[특징] 사상: 리액티브 시스템 [디자인패턴] observer패턴, circuit breaker 패턴
[구조] 서비스 컴포넌트화(fine grained, loosely coupled), 분산거버넌스(polyglot),
분산데이터(vertical slicing), End point 통합(API GW, Orchestraion),
비즈니스 연계(Cross functional Team)		 SPOF 방지 구현을 위해 다수의 API GW 구성가능
API GW, LB, Conway's Law, SOA, DevOps, Docker,
DDD, EDA, Agile
마이크로서비스/모노리틱
토픽 이름 MSA(Micro Service Architecture)
분류 SW > SW Architecture > MSA(Micro Service Architecture)
키워드(암기) API Gateway, Orchestration REST API, Persistent, DevOps,
DDD(Domain Driven Design; 도메인 주도 설계),
Polyglot(폴리글랏): 크로스 플랫폼 적인 데이터 교환를 의미함.
콘웨이의 법칙(Conway’s Law)
암기법(해당경우)  

 

기출문제

번호 문제 회차
1 마이크로 서비스 아키텍처(Micro Service Architecture) 관리 117회 1교시 6번

 

I.  MSA(Micro Service Architecture)개요.

 - 하나의 큰 애플리케이션을 여러 개의 작은 마이크로 서비스 단위로 나누어 변경과 조합이 가능하도록 만든 아키텍처

 

II. 개념도 및 기술요소

 가. 개념도(둘 중 하나 취사선택)

 

 

OR

 

 

나. 구성요소

 

- 대용량 웹 서비스 개발에 적합하게 작은 서비스의 결합을 통해 하나의 응용프로그램을 개발하는 SOA를 근간으로 한 서비스 아키텍처

 

III. 마이크로 서비스 아키텍처와 모놀리식 아키텍처 비교

[추가자료] 마이크로 서비스 아키텍처와 SOA(Service Oriented Architecture) 비교

 

 

[참고] 콘웨이(Conway)의 법칙

•1967년 프로그래머 멜빈 콘웨이가 제안한 법칙

•시스템 구조는 설계하는 조직의 커뮤니케이션 구조를 닮게 된다.

•모든 시스템은 그 조직의 의사소통 구조와 동일하게 만들어진다(닮는다는 의미임).

•조직의 구조가 시스템 아키텍처 설계에 영향을 줌

반응형
저작자표시 비영리 변경금지

'정보관리기술사 > 소프트웨어공학' 카테고리의 다른 글

UML의 관계(Relationship)  (0) 2024.04.04
UML / Diagram 전체  (0) 2024.04.03
SW Architecture 평가  (0) 2024.04.01
ISO/IEC/IEEE 42010  (1) 2024.03.31
명세기반 테스팅 기법  (0) 2024.03.30
상 SW Architecture 평가 [정의] 아키텍처 접근법이 품질속성에 미치는 영향을 판단하고, 아키텍처 적합성을 평가하는 모델
[유형] 시나리오기반, 시뮬레이션기반, 수학적기반, 경험기반
[모델]
시나리오기반(SAAM, ATAM, CBAM, EATAM)
설계혼합기반(ADR, ARID)
 
토픽 이름 (중) SW Architecture 평가
분류 SW > SW Architecture > SW Architecture 평가
키워드(암기) 소프트웨어 아키텍처의 정방향 분석, 소프트웨어 아키텍처의 역방향 분석,
SAAM, CBAM, ATAM, EATAM, ADR, ARID
암기법(해당경우)  

기출문제

번호 문제 회차
1 최근 정부 및 공공기관 소프트웨어 개발 프로젝트에서는 전자정부 표준 공통서비스 및 개발 프레임워크의 적용이 확대되고 있다. 아키텍처 중심의 소프트웨어 개발을 위한 프레임워크 개념과 프레임워크 컴포넌트 구성을 위한 오픈소스 소프트웨어 선정 평가 프로세스에 대하여 설명하시오. 93회_관리_3교시
2 3. 공공부문 EA(Enterprise Architecture) 성과를 평가하는 요소에 대하여 설명하시오. 92회_조직응용_3
3 4. 소프트웨어 아키텍처 평가모델인 ATAM(Architecture Tradeoff Analysis method) 과 CBAM(Cost Benefit Analysis Method)에 대해 프로세스를 중심으로 논하시오. 80회_응용_4
4 6. 소프트웨어 아키텍처 평가모델에 대해 설명하시오. 모의_2019.07_관리_1
5 3. SW 아키텍쳐 분석에 대해 다음 물음에 답하시오.
가. SW 아키텍쳐 분석의 개요
나. SW 아키텍쳐 정방향 분석 및 정방향 분석의 주요 기법인 ATAM
다. SW 아키텍쳐 역방향 분석		 모의_2016.10_관리_2교시
6 SA(Software Architecture) 평가 모델을 분류하고 그 중 ATAM (Architecture Tradeoff Analysis Method), CBAM(Cost Benefit Analysis Method)을 비교하여 설명하시오. 모의_2016.05_관리_2교시
7 SW 아키텍처 평가방법인 ATAM과 CBAM의 평가절차에 대하여 설명하고, CBAM을 기반으로 아래의 사례에 대하여 아키텍처 전략을 선정하시오. 모의_2014.07_공통_2교시
8 소프트웨어 아키텍처 평가방법의 하나인 CBAM(Cost Benefit Analysis Method)의 특징을 설명하고, 평가절차를 상세히 기술하시오. 모의_2013.06_관리_3교시
9 아키텍처 평가방법인 ATAM의 수행단계를 설명하시오. 모의_2012.11_관리_1교시
10 3. SW 아키텍처 평가의 개요, 주요종류 및 수행절차, 기업에 적용 시 문제점과 해결 방안에 대해 기술하시오 모의_2011.12_관리_4교시
11 12. SW 아키텍처 평가의 개념 및 평가 유형을 설명하시오. 합숙_2016.07_관리_1일차
12 CBAM(Cost–Benefit Analysis) 아키텍처 평가방법론을 기반으로 다음의 사례 시나리오를 읽고, 아키텍처 전략을 선정하시오. (가중치와 주어진 업무조건 이외의 내용은 가정하여 제안할 수 있음)
<사례 시나리오>
① POS(Point of Sale) 시스템은 상품에 부착되어있는 바코드를 읽어 들이는 즉시, 재고량이 조정될 수 있고, 소매점 뿐 아니라 대규모 슈퍼마켓으로 확장이 가능
② HA(High Availability)구성을 위해 Heartbeat and cache, Virtual machine, Concurrency 아키텍처 전략 중 하나를 선택하고자 함		 합숙_2012.02_공통_2일차
13 CBAM(Cost–Benefit Analysis) 아키텍처 평가방법론을 기반으로 다음의 사례 시나리오를 읽고, 아키텍처 전략을 선정하시오. (가중치와 주어진 업무조건 이외의 내용은 가정하여 제안할 수 있음)
<사례 시나리오>
① POS(Point of Sale) 시스템은 상품에 부착되어있는 바코드를 읽어 들이는 즉시, 재고량이 조정될 수 있고, 소매점 뿐 아니라 대규모 슈퍼마켓으로 확장이 가능
② HA(High Availability)구성을 위해 Heartbeat and cache, Virtual machine, Concurrency 아키텍처 전략 중 하나를 선택하고자 함		 합숙_2012.02_공통_2일차
14 EATAM(Extending Architecture Tradeoff Analysis Method)을 설명하시오. 합숙_2011.08_공통_2일차
15 SW 아키텍쳐는 설계원칙을 나타내는 상위 수준의 추상화를 의미한다. 이에 따른 요구품질기반 아키텍쳐 수준의 평가방법과 방법론에 대해 논하고, ATAM, CBAM에 대해 설명하시오. 그리고 현재 업무환경에 맞추어 SW 아키텍쳐의 품질평가방법을 제안하고 적용방안을 제시하시오 합숙_2011.02_공통_1일차

 

I. 아키텍처 설계의 검증 방법론, 소프트웨어 아키텍처 평가 개요

가. 소프트웨어 아키텍처 평가의 정의

- 제시된 소프트웨어 아키텍처가 개발될 소프트웨어에 대해서 요구되는 품질 특성을 충족시킬 수 있는지 아키텍처 수준에서 평가하는 절차

 

나. 소프트웨어 아키텍처 평가 방법론 유형

평가유형 내용
Scenario Based
(시나리오 기반)		 - 직접적으로 품질 요소를 위해 미리 정의된 Profile에 의존하여 평가
- 시나리오에 기반하므로 평가 결과도 정밀
- ATAM, SAAM, CBAM 등
Simulation Based
(시뮬레이션 기반)		 - BMT와 같은 시뮬레이션 기반 평가
Mathematical Based
(수학적 기반)		 - 기준 모델을 수치화하고 이를 기초로 평가하는 수학적 기반 모델
Experience Based
(경험 기반)		 - 정량적인 분석이 어려운 경우 적용하는 경험 기반의 평가
- 품질 평가를 위한 정형화된 평가 모델을 갖지 않고 경험을 평가 수단으로 활용

II. 소프트웨어 아키텍처 평가 모델의 관계도 및 상세설명

가. SW아키텍처 평가 모델의 관계도

 

- 일반적으로 ARID와 ADR라는 모듈이나 컴포넌트의 상세 설계 적합성을 검토하는 기법과 함께 사용

 

 

III. 소프트웨어 아키텍처 평가의 기대효과 및 적합성 판단 시 고려사항

가. 소프트웨어 아키텍처 평가의 기대효과

  • 금전적 이익제공, 요구사항의 검증
  • 현재 아키텍처의 문제 조기발견
  • 검토준비의 강제화: 아키텍처의 문서화를 통해 평가 대상자가 적절한 수준의 문서를 획득
  • 논리적 근거 파악: 변경 시 발생할 수 있는 영향 평가
  • 아키텍처 개선: 아키텍처 품질개선

 

나. 소프트웨어 아키텍처 적합성 판단 시 고려사항

  •  아키텍처 평가의 원칙은 아키텍처가 달성해야 하는 목표 식별해 우선순위를 매기는 것.

 -> 이러한 목표들이 아키텍처 적합성을 판단할 수 있는 기준

  •  아키텍처는 한 목표에 대해서는 적합하지만 다른 목표에 대해 적합하지 않을 수 있고 서로 상충 가능
  •  아키텍처 평가는 적합성 판단할 수 있도록 아키텍처 달성 목표에 대해 우선순위 부여하는 과정
반응형
저작자표시 비영리 변경금지

'정보관리기술사 > 소프트웨어공학' 카테고리의 다른 글

UML / Diagram 전체  (0) 2024.04.03
MSA  (0) 2024.04.02
ISO/IEC/IEEE 42010  (1) 2024.03.31
명세기반 테스팅 기법  (0) 2024.03.30
SW Architecture  (0) 2024.03.30
상 ISO/IEC/IEEE 42010
(구 버전 IEEE1471)		 [정의] 시스템, 소프트웨어 및 엔터프라이즈 아키텍처 설명에 대한 요구 사항/표준 용어 정의
[구성요소]
System of Interest,
Architecture,
Stakeholder,
Architecture Description,
Concern,
Architecture Viewpoint(where),
Architecture View(what),
model Kind,
Architecture model,
Architecture Rationale,
Correspondence,
Correspondence Rule
 
토픽 이름 (중) ISO/IEC/IEEE 42010(구 IEEE 1471)
분류 SW > SW Architecture > ISO/IEC/IEEE 42010(구 IEEE 1471)
키워드(암기) System of Interest, Stakeholder, Concerns, Architectural ViewPoint, Model Kind,
Architecture, Architecture description, Architecture View, Architecture Model, Architecture Rationale, Correspondence Rule, Correspondence
암기법(해당경우)  

 

기출문제

번호 문제 회차
1 3. IEEE 1471에 대하여 설명하시오. 98_시스템응용_1
2 아키텍처 표준인 IEEE1471에 대해서 설명하시오 합숙_2012.02_공통_2일차
3 1. IEEE1471 에 대해 설명하시오. 모의_2015.12_응용_1교시
4 아키텍처 표준인 IEEE1471을 설명하고, 소프트웨어 아키텍처의 단계별 산출물과 아키텍처 스타일을 설명하시오. 모의_2009.01_관리_3교시

 

I. SA가 표현해야 하는 내용, 관계정의 표준 프레임워크 ISO/IEC/IEEE 42010(IEEE 1471)의 개요

가. ISO/IEC/IEEE 42010(IEEE 1471)

- 시스템, 소프트웨어 및 엔터프라이즈 아키텍처 설명에 대한 요구 사항/표준 용어 정의

- (목적) 아키텍처를 표현, 전달, 검토하기 위한 개념 제시하고, 아키텍처 설명, 아키텍처 프레임워크 및 아키텍처 설명 언어에 적용되는 요구 사항 지정함으로써 아키텍처 설명의 실무를 표준화

 

나. ISO/IEC/IEEE 42010(IEEE 1471)의 중요성

중요성 설명
표준화 - 아키텍처와 관련된 용어 및 개념의 통일
중립성 - 모델링언어, 방법론 제시 않음, 개발 상위 레벨에서의 SA의 표현
유연성 - 다양한 규모의 시스템 구축 시 적용 가능
의사소통 - 요구사항/설계의 차이를 개선, 이해관계자 관점에서의 표현

 

II. . SW 아키텍처 프레임워크 모델 및 구성요소

가. SW 아키텍처 프레임워크 (ISO/IEC/IEEE 42010가 최종, IEEE 1471 개념적) 모델

프레임워크 내용
IEEE 42010 - 시스템 및 SW엔지니어링 아키텍처기술(Description) 관련된 용어와 개념을 정의한 국제표준, IEEE 1471이 IEEE 42010으로 통합
IEEE 1471 - SW 집약적인 시스템에서 아키텍처가 표현해야 하는 내용 및 이들 간의 관계를 제공하는 아키텍처를 기술하기 위한 표준

나. SW 아키텍처 프레임워크(ISO/IEC/IEEE 42010) 구성요소

분류 구성요소 설명
식별 System of Interest
(대상 시스템)		 - 각 어플리케이션들, 서브 시스템들, 시스템의 집합, 제품라인, 제품 군 등의 구현체

Stakeholder
(이해관계자)		 - <system> individual, team, organization, or classes thereof, having an interest in a system
- 한 명 이상의 System에 대한 이해 당사자로 각자 다른 System에 대한 Concern을 가지고 있는 개인, 기관 등

Concerns
(관심사)		 - <system> interest in a system relevant to one or more of its stakeholders
- 하나 또는 다수의 이해관계자들과 관련 있는 시스템에서의 관심사항
- System의 성능, 유연성, 보안, 분배, 진화 등을 포함한 한 명 이상의 Stakeholder들에게 중요한 System의 개발이나 운영 등 측면
표현 Model Kind
(모델형)		 - conventions for a type of modeling
- 모델링 하는 타입에 대한 방식
- system의 특성 속성에 대한 concern에 대해 기술하기 위한 방식

Architecture
(아키텍처)		 - <system> fundamental cencepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution
- <시스템> 환경에서 시스템의 기본 개념 또는 속성

Architecture description
(아키텍처 기술)		 - work product used to express an architecture
- architecture 표현에 사용되는 방법
- architecture가 기록되는 방법
AD의
파트		 Architectural ViewPoint
(아키텍처 View 관점)		 - work product establishing the conventions for the construction, interpretation and use of architecture views to frame specific system
- 특정 시스템의 관심사항을 만들기 위해 아키텍처 뷰의 구성, 해석, 사용에 대한 규칙을 정립한 work product
- Architecture View를 구성하기 위한 규칙을 정의하는 패턴이나 템플릿

Architecture View
(뷰)		 - work product expressing the architecture of a system from the perspective of specific system concerns
- 특정 System의 관심 있는 부분(concerns, interest)의 관점에서 system의 architecture를 표현한 work product

Architecture Model
(모델)		 - 특정 시스템의 관심사항 작성을 위한 이해관계자들이 가지는 생각이나 견해로부터 시스템을 표현

Architecture Rationale
(결정 근거)		 - 선택되어 설계된 아키텍처에 대한 논리적 근거

Correspondence Rule
(대응 관계의 규제)		 - architecture view들간의 대응 규칙

Correspondence
(대응관계)		 - stakeholder의 관심에 따른 대응 관계
반응형
저작자표시 비영리 변경금지

'정보관리기술사 > 소프트웨어공학' 카테고리의 다른 글

MSA  (0) 2024.04.02
SW Architecture 평가  (0) 2024.04.01
명세기반 테스팅 기법  (0) 2024.03.30
SW Architecture  (0) 2024.03.30
(외부)EPMO  (0) 2024.03.11

+ Recent posts

티스토리툴바