오늘 할일
1. 교수님께 출석 메일 보내기(예비군, 병결)
2. 소웨공 과제 마무리
3. 시험공부 계획 수립
4. 영상처리 공부
5. 트래플 카드 발급??6개월 째 배송중이다..?
6. 인공지능 개론 과제 제출
7. 소웨공 공부디자인 패턴까지
오늘 한일
1. 교수님께 출석 메일 보내기: 예비군이미 처리되어있음, 병결메일전송
- 소웨공 과제 마무리
초안은 완성했으나
-
유스케이스 시나리오에서 다른 유스케이스까지 내용이 넘어가는 부분의 수정이 필요
-
의류 회사가 아닌 의류 관리자를 두어 여러 플랫폼의 의류를 취합하도록 변경할 것인지 검토 필요
-
품질 속성 시나리오가 잘 작성되었는지 확인하기 위해 품질 속성에 대한 추가적인 공부가 필요
-
의류회사->통계 전달 유스케이스 추가
-
품질속성->새로이 작성
-
시퀀스 다이어그램->일부 작성오류 수정(유스케이스 다이어그램과 일치)
최종본 완성
- 시험공부 계획 수립
- 인공지능 개론: 교수님이 시험문제를 찝어주셔서 1시간 요약정리+30분 공부로 충분할 듯 함. 수식 안나오고 6장~11장까지
- 영상처리: chap 7, 8, 10이 시험범위인데 공부가 가장 어려울 것으로 보임. 최대한 빠르게 1회독 후 질문을 추려 교수님께 질문하는 시간을 가지는게 가장 중요함. 최소 하루를 풀로 잡아야 가능+chap10연습문제 과제 제출이 예상됨
- 모바일 프로그래밍: 영상처리 다음으로 범위가 가장 많은 강의. 코드를 세세하게 보고 교재의 연습문제 및 그 이전의 개념 요약을 꼭 봐야함. 마찬가지로 하루를 풀로 잡아야 가능
- 알고리즘: 룩업테이블, 후위표기식 변환, 연결리스트, 구조체 포인터, 잘려진 소수점 합, 동적할당을 이용한 구조체의 연결리스트, 버블정렬, 삽입정렬, 퀵정렬, 합병정렬 로 이 역시 하루를 풀로 잡아야 하..ㄹ정도는 아닌데 3/4하루 정도는 잡아야 할듯. 과제가 있다면 과제하면서 하면 될듯.
- 소웨공: 당장 내일 모레인 시험인데, 주요 개념들을 정리하는게 가장 중요해보임. 이때 어설프게 아는 것이 아닌 서술형문항으로 자세하게 설명 가능할 정도여야하고, 영어 약자에 대해 잘 파악하고 있어야함. ISO표준 등도 잘 기억하자.
Usecase, Sequence 다이어그램등을 그릴 수 있고, 품질공학을 할 수 있어야한다. 알고리즘과 같이해도 될 양인 듯 함.
-전체 일정 정리:
- 6/3(월) 소웨공 공부 및 과제 완성(feat. +-영상처리 과제)
- 6/4(화) 영상처리 공부 완료
- 6/5(수) 소웨공 공부 및 시험 응시, 알고리즘 공부 완료
- 6/6(목) 휴식
- 6/7(금) 모바일 프로그래밍 공부 끝, 인공지능 개론
- 6/8(토) 휴식_생일
- 6/9(일) 인공지능개론, 영상처리 직전공부, 알고리즘 공부
- 6/10(월) 인공지능 개론, 영상처리 시험 응시 / 모바일 프로그래밍 직전 공부
- 6/11(화) 모바일 프로그래밍, 알고리즘 시험 응시
- 소웨공 공부
[03. UML]
1. Activity Diagram
-시스템에서 발생하는 액션이나 동작을 단계적으로 표현하기 위한 다이어그램
-순서도와 유사
-객체의 행위를 나타내며 상태 다이어그램(특정 객체 내부 or 시스템 전체의 자세한 동작 술)의 확장형태
-비지니스 프로세스 모델링에 사용
-상위수준: 업무의 흐름을 표현
-분석단계: 유스케이스의 구체적인 흐름(시나리오) 표현
-설계단계: 클래스 내부 동작 알고리즘 or 구체적인 로직의 표현
-구성요소: 시작점(원), 종료점(이중원), 활동&액션(둥근네모), 전이(화살표[con]), 파티션, 포크(두꺼운바), 조인(두꺼운바), 의사결정(마름모), 클래스(네모)
-활동은 특정 작업을 수행하는 단위(작업, 프로세스, 상태, 동작 등)인 반면 액션은 특정 시점의 단일 객체 작업(구체적인 동작, 활동)이다.
-시작과 종료는 반드시 존재
-사건 발생에 관련된 객체들의 상하 관계등을 일렬로 도식화
-단계별 활동과 다음 활동을 흐름에 따라 표시
-여러 시스템 혹은 사용자와의 관계를 표시하기 위해 구획을 사용할 수 있음
-여러 파티션으로 역활을 구분하고 병렬처리를 표현할 수 있다.
-그려보기
Requested_Order클래스를 받는 Receive Order활동을 시작점으로 한다. 주문이 받아졌다면 Fille Order활동을 거쳐 병렬작업으로 Ship Order와 Send Invoice를 수행한다. Send Invoice는 Invoice클래스를 생성하고 Make Payment활동, Accept Payment활동을 수행한 뒤 서로 join한다. 그 뒤 특정 클래스 A에 대한 의사결정을 수행한 뒤 Close Order활동을 수행한 뒤 종료한다.
2. Component Diagram
-컴포넌트강의 관계를 구조적으로 표현하는 다이어그램
-인터페이스를 포함하는 소프트웨어 컴포넌트를 의미
-어떤 실행 모듈이 존재하고, 이들간의 연관성이 있는지에 대한 종속성을 보여준다
-사용자에게 논리적 혹은 물리적인 시스템 구조를 전달한다
-아키텍처 설계 시 Runtime View(Component & Component View)의 주요 산출물로 중요한 도구이다.
-컴포넌트는 UML에서 시스템을 구성하는 물리적 요소의 의미와 달리 Component Based Development에서 인터페이스에 의해 기능의 정의된
독립적인 개발, 배포, 조립이 가능한 시스템의 구성단위를 의미한다. 아키텍처 관점에서는 실행중인 소프트웨어 모듈의 의미로, 분리되어있는
회원 컨트롤러, 주문 컨트롤러를 실행 관점에서 웹 컴포넌트의 개념으로 볼 수 있다.
-구성요소: 컴포넌트(여러 물리적인 모듈_패키지를 포함하고 있는 특정 영역_역할을 수행하는 그룹), 인터페이스(컴포넌트가 실현하고자 하는
여러 기능의 집합, 컴포넌트가 제공하는 API형태의 서비스를 정의), 관계(의존관계와 실체화 관계)
-컴포넌트 대상 정의: 실행 모듈 혹은 소스코드 등 어떤 것을 컴포넌트로 설정할지 대상을 정의
-컴포넌트 식별: 다이어그램에 포함 될 컴포넌트를 식별
-컴포넌트 배치: 컴포넌트를 다이어그램에 표현하고 이름을 정의
-관계 정의: 컴포넌트 간 의존관계를 정의하는데, 경우에 따라 인터페이스 추가하여 실체화 관계로 작성
-컴포넌트는 스테레오 타입으로 <<component>>로 표시
-양 옆으로 Ports를 네모로 표현하며, 인터페이스와 연결을 시켜준다.
-인터페이스는 Required Interface는 반원, Provided Interface는 원으로 표현한다.
-내부 객체(클래스)는 :Entry등과 같이 네모로 표현한다.
-외부 인터페이스 연결 시에만 네모(port)를 표현하고, 내부 인터페이스간은 단순히 연결시킨다.
- 종속관계는 ->를 통해 순서도와 같이 나타내며 별다른 종속관계가 없는 내부 클래스 간 관계 등을 비롯한 그 외 관계는 그냥 선으로 이어준다.
-외부 port와 내부 객체가 반드시 연결되지 않아도 된다. 내부에는 선으로 다 연결시켜주는 듯 하다. 내부에 아무것도 없어 port만 연결해주는거 제외
-그려보기
컴포넌트 BlogDataSource는 외부에서 제공된 DataSource인터페이스를 Delegation connector포트로 받아 내부객체 Blog에 전달한다. 내부객체 Entry는 Delegation connector 포트를 이용해 Logger 필수 인터페이스와 연결된다.
다음의 디자인 패턴 맞추기
1. 
2. 
3. 
4. 
5. 
6. 
7. 
8.
9. 
10. 
11. 
12. 
13. 
14. 
15. 
16. 
17. 
18. 
19. 
20. 
21. 
22. 
23. 
[04. 디자인 패턴]
1. 디자인 패턴은 소프트웨어를 설계할 때 특정 상황에서 반복적으로 발생하는 고질적인 문제들에 대한 재사용 가능한 해결책이다.
2. 건축가 크리스토퍼 알렉산더의 책에서 처음 사용되었다.
3. GoF(Gans of Four)디자인 패턴은 "Design Patterns"책에서 소개된 디자인 패턴이며 저자의 이름을 땄다.
4. Object Oriented Programming, Unified Modeling Language, SOLID, GRASP 디자인 원칙에 대한 이해가 있어야 한다.
5. 생성패턴, 행위패턴, 구조패턴으로 분류되는 총 23개의 패턴이 있다. 구현언어에 의존하진 않지만 객체지향을 기본으로 한다.
6. Context는 문제가 발생하는 상황(패턴이 적용될 수 있는 상황), Problem은 패턴으로 해결될 필요가 있는 디자인 이슈들(제약사항과 영향력도 고려), Solution은 문제를 해결하기 위한 설계의 구성요소와 객체들의 관계, 책임, 협력 등을 기술(구체적인 구현방법이나 언어에 의존하지 않는 템플릿)
7. 상속, 합성, 위임
-상속: 기존 클래스의 특성을 물려받는 새로운 클래스를 만드는 것으로, 단순히 코드 재사용아니 편의를 위해 사용하면
자식-부모 클래스 간 불필요한 강한 결합이 생겨 자식이 부모에게 의존하게 된다.
부모가 변경되면 자식도 변경되어야 하기에 유지보수가 어렵고, 코드의 재사용성이 떨어지며, 코드에 의한 영향도(코더 재량)가 높아진다.
is-a를 충족하는 경우에만 사용하며, 코드 재사용이 아닌 확장을 위해 사용되며, 상속을 아예 사용하지않고 합성하여 사용하는 것을 권장한다.
-합성: 다른 클래스(객체)를 여러 개 붙여 새로운 객체를 구성하는 것으로 has-a관계이다.
구체클래스를 상속받을 경우 상속대신 private필드를 통한 참조를 만들어 구현하는 접근방식이다(Order클래스 안에 PayMethod)
-위임: 특정 처리를 다른 객체에게 위임하는 것으로, 상속과 합성을 통해 구현된다. 역활과 책임의 명확화라는 관점에서 책임을 가지는 객체에 처리를
위임하는 것이 좋다는 개념이지만 특정 클래스가 자신이 제공하는 기능은 없으면서 모든 메서드가 위임만으로 구성되는 것은 바람직 하지 않다.
합성의 대표적인 구현방법으로 Delegation Pattern이라고도 하며, Proxy & Chain of Reponsibility등 여러 패턴에서 활용된다.
(Service에 save를 controller에서 호출. 약간 생성자 오버로딩 시 기본생성자 돌려쓰는 느낌)
8. 패턴 사용 시 주의점: 과다한 패던 사용으로 복잡도 증가, 많은 패턴을 사용해야한다는 스트레스, 패턴 사용으로 비효율 발생, 언어 특성에 따른 유연한 적용
9. 창조패턴: 객체의 생성과 참조 과정을 추상화/캡슐화해 특정 객체의 생성 과정을 분리하기 위한 패턴으로 5가지 인스턴스화 문제를 해결
객체생성이 복잡함, 반복적인 객체생성, 객체생성에 많은 비용소모, 지나친 객체생성으로 자원 낭비, 객체생성에 유연성이 필요
-추상팩토리: 구체적인 클래스 생성을 지정하지 않고, 관련성이 있거나 독립적인 객체들을 생성하기 위한 제품 객체군에 대한 인터페이스 제공
-빌더: 여러 구성요소로 이루어진 복합 객체의 생성 과정과 표현 과정을 분리시켜 동일한 생성과정을 통해 다양한 객체를 생성.
ex) url API호출시 http와 파라미터 조합 / 복합 객체의 생성과정과 표현과정을 분리, 생성할 객체의 옵션이 많은 경우, 생성자에 다양한 인자
여러 빌더를 포함한 Director, Builder 인터페이스와 Concret Builder 클래스로 구성. 자바에서 메서드 체이닝 방식으로 Builder인터페이스
없이 ConcretBuilder 클래스 만으로도 많이 사용
-팩토리 메서드: 객체를 생성하는 인터페이스를 정의하지만, 인스턴스 생성 부분은 서브클래스에 위임하여 간단하며 확장가능한 팩토리
Creator 추상 클래스를 상속하는 Concrete Creator 클래스에서 템플릿 메서드 factoryMethod()를 오버라이딩해서 객체 생성
-프로토타입: 새로운 객체를 프로토타입(기존 인스턴스)를 복제하여 생성. 객체생성이 오래걸리거나 자원이 많이 드는데 비슷한 객체가 있으면 사용.
자바에서 Object클래스의 .clone()으로 구현. deep clone(primitive), shallow clone(List, String 등 참조형)등의 문제고려가 필요
-싱글턴: 클래스의 인스턴스가 하나임을 보장하고 접근할 수 있는 전역적인 접근점을 제공. 자원낭비를 막고 일관성있는 처리. Spring의 Bean
자바에서 static final로 eager initialization(클래스 로딩과정에서 일찍 초기화. 그냥 지연초기화의 반대개념)으로 간단히 구현가능
사용하지 않는 경우 자원낭비가 되기에 static final var=new ...하는 eager initialization방식보다 static class내부에 static final인스턴스를 가지고
SingletonHolder.INSTANCE를 반환하는 static inner방식이 좋다.
10. 구조패턴: 클래스나 객체를 조합해 더 큰 구조를 만드는 패턴
-어댑터(래퍼): 클래스의 인터페이스를 다른 인터페이스로 변환하여 기존 코드와 수정없이 호환성을 유지.
구조화되지 않은 설계에 새 규격 구현에서도 사용. 기존 규격과 새 규격을 모두 상속받는 경우 다중 상속 문제가 발생할 수 있기에
임시적인 문제해결이며, 새 규격을 컴퍼지트 패턴으로 위임하는게 좋다
-브릿지: 구현부에서 추상층을 분리하여 각자 독립적으로 확장할 수 있도록 하는 패턴. 객체의 확장성 향상을 위해 구현부(기능)과 추상부를 분리
변화에 유연성, Abstraction은 구조적인 부분을 정의, 구현부는 Implementor에 위임. 확장이 필요한 경우
Abstraction을 상속받고 여러 Implementor를 구현하여 구조의 확장과 처리방법의 확장을 분리
-컴퍼지트: 객체들의 관계를 트리 구조로 구성하여 복합 객체와 단일 객체를 구분없이 다룰 수 있도록 하는 패턴. 트리구조로 전체-부분 관계를 표현
복합객체와 단일객체를 구분없이 다룰 수 있으며 동일한방식으로 처리하기에 구현관점에서 유용. ex) 디렉토리-파일, 부서-팀, 패키지-상품
-데코레이터: 동적으로 객체를 결합하기 위해 객체지향 구성을 확장하는 패턴으로 복합객체와 위임을 통해 상속이 아닌 합성을 통한 확장을 지원
기존코드를 변경하지 않고 부가기능을 동적으로 추가, 특정 객체에 다른 객체를 가지는 구조를 반복추가하여 확장,
실제 구현 형태는 언어마다 다름. 객체생성시 객체를 래핑해서 조합
-파사드: 서브시스템에 있는 인터페이스 집합에 통합된 하나의 인터페이스를 제공.
개별 인터페이스는 ISP원칙을 따라야 하며, 코드의존성을 줄이고 느슨한 결합으로 연결성과 종속성을 최소화한다.
크기가 커지면 복잡도가 증가된다. 서비스 시스템을 직접 호출하지 않기에 오용을 방지하고,
내부와 외부를 구분하여 서브시스템 업그레이드에 자유롭다. ex) 공개기능과 비공개기능
-플라이웨이트: 공통으로 사용하는 클래스를 생성하는 팩토리 클래스를 만들어 인스턴스를 최초 1개만 생성하고 공유하여 재사용
객체가 많은 메모리를 차지하는 경우에 사용되며 가능한 같은상태객체는 재활용하고,
새로운 상태가 필요한 경우에만 생성(별도 팩토리 클래스)*, FlyweightFactory는 플라이웨이트 객체를 관리하고 생성.
Client는 플라이웨이트팩토리로 플라이웨이트 객체 사용
-프록시: 다른 객체 접근을 통제하기 위해 객체의 surrogate or placeholder를 제공. 객체의 정교한 제어, 객체참조에 사용
원격 프록시, 가상 프록시, 보호 프록시로 구분. ex) 신용카드를 현금처럼 사용.
동일한 인터페이스를 가진 객체를 사용하기 위해 Subject 인터페이스 정의, 구현 객체는 직접 사용하거나 특정 컨트롤이 필요한 경우
Proxy객체를 사용. 클라이언트는 두 객체가 동일하기에 동일한 방법으로 사용
11. 행위패턴: 클래스나 객체들이 서로 상호작용하는 방법이나 작업, 알고리즘 등을 어떤 객체에 할당하는 것이 좋을지 결정
-책임연쇄: 요청을 받는 객체를 연쇄적으로 묶어 요청을 처리하는 객체를 만날 때 까지 객체 체인을 따라 요청을 전달
ex) try catch, Logger, 스프링의 서블릿 필터, 인터셉터, 핸들러
-커맨드: 요청을 객체의 형태로 캡슐화해 재사용하거나 취소할 수 있음. 상호작용을 캡슐화하여 객체 결합도를 줄이고, 확장구조를 제공.
on, off를 와이퍼나 오디오 여러가지에 전달. Concrete Command에서 Receiver의 액션을 통해 동작을 수행.
Invoker는 이벤트를 발생시키는 컨트롤러, Receiver는 커맨드를 수신하는 객체로 실제 동작이 처리되는 대상
-인터프리터: 문법적 규칙을 클래스화하여 일련의 규칙을 통해 언어/문법을 해석. 특정 문제 영역에 대한 해결
규칙을 Abstract Expression인터페이스로 정의하고 서브 표현식을 포함하는지에 따라 TerminalExpression(종료가능)와
NonterminalExpression (다른 Expression을 참조)클래스로 구성. 정규표현식과 DSL(Domain Specific Language)에 사용
-이터레이터: 내부를 노출시키지 않고 다양한 구조의 집합형 객체 원소를 순차적으로 접근할 수 있는 동일한 인터페이스를 제공 next(), hasNext()
Aggregate는 집합형 객체의 규격을 제공하는 인터페이스, Iterator는 단일한 접근법을 위한 기능 집합 ex)자바 컬렉션 프레임워크
-미디에이터: 한 집합에 속한 객체들의 상호작용을 캡슐화해 새로운 객체로 정의. 특별한 중재자의 간접 통신으로 구성요소간 결합을 줄임.
다른 구성요소에 지나치게 의존해 재사용이 불가능한 경우 사용. ex) n:n관계를 n:1 1:n으로 분리.
특정 객체들의 그룹을 정의하는 인터페이스 Colleague간의 상호작용을 중재. Controller나 Service객체에 사용
-메멘토: 객체가 특정 상태로 다시 돌아올 수 있도록 내부 상태를 실체화. 상태를 가진 객체(스냅샷)을 별도관리객체에 보관해 원하는 시점의 상태복원
Originator클래스는 Memento객체 생성 및 복원 메서드 제공, Memento는 Originator 객체의 상태를 저장,
Caretaker는 생성된 Memento객체들을 관리 ex) 자바 객체 직렬화(파일로 저장)
-옵저버: 객체 상태가 변할 때 관련 객체들이 변화를 통지받고 자동갱신. 데이터변경 시 상대 객체에 의존하지 않고 데이터 변경을 통보할때 사용.
특정 상태의 변화를 통보받는 객체 Observer, 관심대상은 Subject인터페이스. Subject에서 Observer객체를 등록/삭제/통보 메서드 제공
publish-subsribe모델(비동기 메시지)과 유사
-스테이트: 일련의 규칙에 따라 객체의 상태를(클래스로 선언하고) 변화시켜 객체의 행위를 바꾸는 패턴
ConcreteState클래스에서 상태에 따른 처리를 구현, Context클래스에서 상태를 변경하고 처리하는 걸 State객체에 위임. Strategy패턴유사
-스트래티지: 알고리즘들을 정의하고 캡슐화하여 상호교환 가능하게 만드는 패턴. 변경되는 것이 메서드(행위) 일 때
조건에 따라 다른 메서드 호출 혹은 내부적인 수정을 통해 구현하는 것이 아닌 클래스로 캡슐화하여 알고리즘의 대체가 가능.
알고리즘을 Strategy인터페이스에서 정의, ConcreteStrategy클래스에서 구현, Context클래스에서 Strategy인터페이스를 통해
알고리즘 사용. DI구조로 동적 알고리즘 교환이 가능
-템플릿 메서드: 상위 클래스에서 알고리즘의 골격만 작성하고 구체적인 처리를 서브클래스로 위임. 추상클래스의 특징을 사용한 패턴.
규격으로 처리되어야하는 부분과 구체적인 처리를 분리하여 확장성이 높다.
-비지터: 객체의 원소에 대해 수행할 연산을 분리하여 별도의 클래스로 구성하는 패턴으로 로직과 구조를 분리. 연산에 대한 부분을 위임
콜백과 유사하며, Element에서 특정 Visitor를 받아 구현체의 메서드를 호출하여 처리
[06. 품질속성]
1. 소프트웨어 아키텍처: 품질 속성을 충족하는 소프트웨어 시스템의 구조. 품질속성은 소프트웨어 아키텍처 설계의 목표이며, 소프트웨어 아키텍처
설계의 결과물은 품질 속성을 만족시키는 소프트웨어 시스템의 구조가 된다.
2. 품질 속성은 비기능 요구사항이며, 비기능 요구사항이 그대로 품질속성이 되기도 한다.
3. ISO 25010 System/Software Product Quality에 정의되어 있으며 품질 특성이라고도 한다.
4. ISO 25010은 소프트웨어 품질 평가의 관점이고,
개발 관점에서는 특정 품질 속성을 어떤 설계를 통해 충족시킬 것인지(설계 기법)를 품질속성 시나리오로 표현한다.
5. ISO 25010사용 시 주의사항:
-원문으로 이해
-요구되는 속성이 어떤 범주에 들어가는지 구분하는 정도로 사용(정확한 적용보다는)
-다양한 소프트웨어 종류마다 요구되는 품질 특성에 차이가 있다.
-해당 품질 특성을 명시한다는 것은 요구수준 충족에 어려움이 있다는 것을 의미한다.(달성해야하는 목표니까)
-아키텍처 관점에서는 문제를 어떤 방법으로 해결해 품질 속성을 충족시킬지 고민해야한다.
6. ISO 25010 System/Sortware Product Quality는 크게 8가지 범주로 구분된다.
7. Functional Suitability(기능 적합성): 시스템이 명시된 조건에서 요구된 기능을 충분히 제공하는 정도. 요구사항을 정확히 만족하는 기능을 제공하는지 평가
-Functional Completeness(기능 완전성): 명시된 요구사항을 충족하는 정도
ex)요구기능은 95%이상 구현, 개발앱은 서비스 기능을 모두 제공해야함
-Functional Correctness(기능 정확도): 특정 기능이 어느정도의 정밀도(기능 동작의 정확도)를 제공해야하는가?
ex) 얼굴인식 95%이상, 환불 3일내 100%
-Functional Appropriateness(기능 적합성): 특정 기능이 명시된 작업 및 목적을 적합하게 달성하는지
ex) 환불을 사용자에게 적절한 방법으로, 자동오류감지는 오동작 예방에 적합하게 제공
8. Performance Efficiency(성능 효율성): 시스템이 요구되는 성능을 얼마나 효율(비용)적으로 제공하는지
- Time Bebavior(시간반응성): 시스템이 어느 정도 수준의 응답, 처리시간, 처리율을 충족하는지
ex) 얼굴인식 촬영후 1초이내, 주문은 실시간으로 대시보드에 반영, 100대장비 요청처리에 지연x
-Resource Utilization(자원 활용도): 시스템이 얼마나 효율적으로 자원을 사용하는지
ex) 80%이상의 CPU사용률, 추가 확장없이 동시 10000명접속 처리, 전력소모량은 peek에도 80%이내
-Capacity(수용역량): 시스템이 최대 수용할 수 있는 정도
ex)동시접속사용자는 인프라확장없이 최대 50000명, 거래처리량 10000TPS이상 유지
9. Compatibility(호환성): 시스템이 동일한 SW/HW 환경을 공유하며 다른 시스템과 공존하거나 호환될 수 있는 정도
-Co-existence(공존성): 시스템이 공통 환경 및 리소스를 공유하면서 효율적으로 기능을 수행할 수 있는 정도(공존할 수 있는 정도)
ex) 개발시스템은 기존판매시스템과 동시운영, docker로 단일서버노드에 여러 서비스를 독립적으로 운영
-Interoperability(상호운용성): 시스템이 다른 시스템과 정보를 교환하거나 교환된 정보를 이상 없이 사용하며 상호 운용할 수 있는 정도
ex) 스마트폰 API서버는 PC나 웹과도 상호운용, 개인건강디바이스는 삼성헬스랑도 상호운용 가능
10. Usability(사용성): 목적 달성을 위해 시스템이 사용자에게 얼마나 쉽게 사용될 수 있는지(사용자 중심의 시스템 설계 UI/UX디자인)
-Appropriateness Recognizability(인식 적합성): 시스템이 사용자에게 필요성을 얼마나 적합하게 인지시키는가?
ex) 메인 디스플레이는 사용자가 필요로하는 정보를 쉽게 인지, 차량 내 조작버튼은 필요시점에 적절히 제공
-Learnability(학습성): 사용자가 시스템을 쉽게 학습하고 사용할 수 있는지
ex) 개발앱은 1시간 이내에 사용가능, 신규 시스템 전환 시 담당 직원은 3일이내 학습
-Operability(운용성, 조작성): 사용자가 쉽게 운용하고 제어할 수 있는 수준
ex) 개발앱은 다양한 모바일에서 쉽게 조작, 비가와서 터치가 안되도 음성등 다른 조작을 제공
-User Interface Aesthetics(사용자 인터페이스 미학): 유저 인터페이스가 얼마나 간결하고 보기 좋고 만족스러운 상호작용을 촉진하는지
ex) 개발앱 UI는 시야분산없이 직관적으로 기능 제공, 광고노출은 조작에 방해x
-User Error Protection(사용자 오류 보호): 사용자 오류로부터 시스템이 얼마나 보호될 수 있는지
ex) 사용자가 실수로 삭제할 경우 방지, 광고 노출 형태는 조작에 방해x? Q.
-Accessibility(접근성): 시스템을 다양한 연령, 성별, 장애유무, 언어, 문화, 인종에 따라 명시된 목표를 달성하며 사용할 수 있는 정도
ex) 고객 지원 서비스는 외국인도 가능, 노안사용자도 개발앱 쉽게 이용
11. Reliability(신뢰성): 시스템이 얼마나 오류없이 안전하게 작동할 수 있는지를 평가
-Maturity(성숙도): 시스템이 정상환경에서 얼마나 신뢰할만큼 결함고장이나 오류 없이 안정적으로 작동하는가?
ex) 리소스 80%수준까지는 안정적으로 작동, PG연동오류에서 결제처리가 완료된 것으로 나오거나 중복결제x
-Fault Tolerance(오류 내구도): 시스템이 장애나 오류로부터 의도한 수준의 성능을 유지할 수 있는 정도
ex) 시스템은 데이터베이스 장애 상황에서도 결제기능은 정상작동해야한다, 디바이스 장애 발생 시 서비스는 정상동작
-Recoverability(회복정도); 장애나 문제 발생 시 시스템이 요구되는 수준의 성능으로 회복되며 복구되는 수준
ex) DB장애동안 발생한 트랜잭션은 복구 후 정상반영, 복구불가상태에서 신규기기로그인 시 이전 데이터 복구
-Availability(가용성): 시스템이 얼마나 원하는 시점에 사용할 수 있는지. **다른 품질속성이 충족되지 않았을 때 가용성이 떨어질 수 있으니 품질속성 문제를 큰 범위인 가용성문제로 접근하는 것은 좋지 않다.**
ex) 시스템은 연간 99.99%가용성 유지, 긴급정지기능은 프로세스진행중에도 사용가능
12. Security(보안성): 시스템이 얼마나 보안을 유지할 수 있는지(항상 고려해야함),
우리 시스템에서 직접 해결할 수 없는 하드웨어 등의 문제는 별도 가정사항에 정의
-Confidentiality(기밀성): 제품이 승인된 주체에게만 데이터 접근성을 보장하는가?
ex) 판매자 메뉴는 인증된 판매자만 접근, 개인정보는 인증된 사용자만 접근
-Integrity(무결성): 시스템이 얼마나 정보가 변형되거나 손상되는 것을 방지할 수 있는가?
ex) 자회사정보는 본사에서도 변경불가, 개별의 수정이 통합의 원본에도 동일히 수정, 시스템 이외 데이터 변경 불가
-Non-Repudiation(부인 방지): 시스템이 작업이나 이벤트를 결정적으로 검증할 수 있는가?
ex) 수신 및 내용 확인을 부정할 수 없어야 함, 고지서 수신 확인 후 처리결과 이의제기시 수신확인을 검증할 수 있어야함
-Accountability(책임 추적): 특정 작업을 수행한 사용자를 추적할 수 있는가?
ex) 시스템의 모든 조작 결과에 대한 사용자 정보 추적가능, 담당 업무별 사용자 권한 체계에 따라 사용자 조작결과 추적
-Authenticity(인증성): 주체 또는 리소스의 신원을 확실하게 확인할 수 있는가?
ex) 시스템은 사용자의 인증정보를 확인할 수 있다, 사용자 등록은 인증성 보장을 위해 별도의 인증과정을 거침
13. Maintainability(유지보수성): 시스템이 얼마나 쉽게 변경 및 유지보수가 가능한지 평가(빠른 변화 수용 및 개선에 중요)
-Modularity(모듈성): 시스템이 변경의 영향을 최소화하기 위해 개별 구성요소로 구성되어 있는가?
ex) 시스템의 핵심 feature들은 독립적인 모듈로 구성되어야 함, 모듈간 결합도는 모듈 수정에 영향을 주지 않는다
-Reusability(재사용성): 시스템을 다른 곳에서 사용하거나 다른 시스템 구축에 활용할 수 있는가?
ex) 인증 모듈은 다른 시스템에서도 재사용할 수 있음, 부품판매시스템은 자동차판매시스템에서도 재사용할 수 있음
-Analyzability(분석성): 시스템의 문제점을 분석하고 수정할 수 있는 정도(의도한 변경, 결합, 장애에 대해 제품을 효과적으로 평가할 수 있는가?)
ex) 시스템 문제 진단 가능, 소프트웨어 변경추적, 고장 및 오류추적이 가능
-Modifiability(변경성): 결함이나 품질저하 없이 제품을 효과적으로 수정할 수 있는가?
ex) 특정 모듈 수정 시 다른 모듈에 영향x, 운영중인 시스템에 서비스 중단 없이 변경사항 반영
-Testability(테스트 용이성): 시스템이 테스트하기 쉬운지
ex) 효과적인 기준을 설정하고 테스트 할 수 있음, 테스트를 통해 모든 기능에 대한 검증이 가능
14. Portability(이식성): 서로 다른 환경 간에 시스템을 쉽게 이전할 수 있는 정도를 평가
-Adaptability(적응성): 다른 SW(HW)나 환경에 효과적이고 효율적으로 적용할 수 있는 정도_Reuseability와 혼동주의 Reuse는 목적이 바뀜
ex) 개발된 사용자 인증 서비스는 다른 서비스에 쉽게 적용, 새로운 혈당계 도입 시 기존 시스템에 쉽게 적용
-Installability(설치용이성): 시스템의 설치/제거가 용이한 수준
ex) 클라우드 서비스 벤더 교체에도 시스템 설치 추가비용이 발생x, 운영 노드에서 최소한의 시간으로 특정 서비스 제거
-Replaceability(대체용이성): 제품이 동일한 환경에서 다른 제품으로 대체될 수 있는 정도_이것도 Reuseability, Adaptability와 혼동주의 Q. 통계도구?
ex) 개발 시스템의 로그인 모듈은 다른 로그인 모듈로 대체가능, 앱의 UI라이브러리를 다른 라이브러리로 대체 가능
15. Maintainability->Reuseability와 Portablility->Adaptabilty와 Portablity->Replaceability의 구분이 애매모호
Reuseability는 특정 시스템을 그대로 다른 시스템에 재활용할 수 있는지 ex) 회원로그인 모듈을 관리자로그인 모듈에 재활용
Adaptabilty는 다른 운영체제에서도 사용할 수 있는지 ex) 모바일에서도 웹 사이트 확인 가능
Replaceability는 모듈성이 좋아서 교체해도 아무 티가 안나는거 ex) 로그인을 카카오로그인에서 네이버로그인으로 변경
전자는 모듈 재활용, 중자는 이식성, 후자는 교체 느낌인가?예시만 보고 품질속성 맞추기 필요.
ex) 개발 시스템의 로그인 모듈은 다른 로그인 모듈로 대체가능, 앱의 UI라이브러리를 다른 라이브러리로 대체 가능
ex) 클라우드 서비스 벤더 교체에도 시스템 설치 추가비용이 발생x, 운영 노드에서 최소한의 시간으로 특정 서비스 제거
ex) 개발된 사용자 인증 서비스는 다른 서비스에 쉽게 적용, 새로운 혈당계 도입 시 기존 시스템에 쉽게 적용
ex) 효과적인 기준을 설정하고 테스트 할 수 있음, 테스트를 통해 모든 기능에 대한 검증이 가능
ex) 특정 모듈 수정 시 다른 모듈에 영향x, 운영중인 시스템에 서비스 중단 없이 변경사항 반영
ex) 시스템 문제 진단 가능, 소프트웨어 변경추적, 고장 및 오류추적이 가능
ex) 인증 모듈은 다른 시스템에서도 재사용할 수 있음, 부품판매시스템은 자동차판매시스템에서도 재사용할 수 있음
ex) 시스템의 핵심 feature들은 독립적인 모듈로 구성되어야 함, 모듈간 결합도는 모듈 수정에 영향을 주지 않는다
ex) 시스템은 사용자의 인증정보를 확인할 수 있다, 사용자 등록은 인증성 보장을 위해 별도의 인증과정을 거침
ex) 시스템의 모든 조작 결과에 대한 사용자 정보 추적가능, 담당 업무별 사용자 권한 체계에 따라 사용자 조작결과 추적
ex) 수신 및 내용 확인을 부정할 수 없어야 함, 고지서 수신 확인 후 처리결과 이의제기시 수신확인을 검증할 수 있어야함
ex) 자회사정보는 본사에서도 변경불가, 개별의 수정이 통합의 원본에도 동일히 수정, 시스템 이외 데이터 변경 불가
ex) 판매자 메뉴는 인증된 판매자만 접근, 개인정보는 인증된 사용자만 접근
ex) 시스템은 연간 99.99%가용성 유지, 긴급정지기능은 프로세스진행중에도 사용가능
ex) DB장애동안 발생한 트랜잭션은 복구 후 정상반영, 복구불가상태에서 신규기기로그인 시 이전 데이터 복구
ex) 시스템은 데이터베이스 장애 상황에서도 결제기능은 정상작동해야한다, 디바이스 장애 발생 시 서비스는 정상동작
ex) 리소스 80%수준까지는 안정적으로 작동, PG연동오류에서 결제처리가 완료된 것으로 나오거나 중복결제x
ex) 고객 지원 서비스는 외국인도 가능, 노안사용자도 개발앱 쉽게 이용
ex) 사용자가 실수로 삭제할 경우 방지, 광고 노출 형태는 조작에 방해x? Q.
ex) 개발앱 UI는 시야분산없이 직관적으로 기능 제공, 광고노출은 조작에 방해x
ex) 개발앱은 다양한 모바일에서 쉽게 조작, 비가와서 터치가 안되도 음성등 다른 조작을 제공
ex) 개발앱은 1시간 이내에 사용가능, 신규 시스템 전환 시 담당 직원은 3일이내 학습
ex) 메인 디스플레이는 사용자가 필요로하는 정보를 쉽게 인지, 차량 내 조작버튼은 필요시점에 적절히 제공
ex) 스마트폰 API서버는 PC나 웹과도 상호운용, 개인건강디바이스는 삼성헬스랑도 상호운용 가능
ex) 개발시스템은 기존판매시스템과 동시운영, docker로 단일서버노드에 여러 서비스를 독립적으로 운영
ex)동시접속사용자는 인프라확장없이 최대 50000명, 거래처리량 10000TPS이상 유지
ex) 80%이상의 CPU사용률, 추가 확장없이 동시 10000명접속 처리, 전력소모량은 peek에도 80%이내
ex) 얼굴인식 촬영후 1초이내, 주문은 실시간으로 대시보드에 반영, 100대장비 요청처리에 지연x
ex) 환불을 사용자에게 적절한 방법으로, 자동오류감지는 오동작 예방에 적합하게 제공
ex) 얼굴인식 95%이상, 환불 3일내 100%
ex)요구기능은 95%이상 구현, 개발앱은 서비스 기능을 모두 제공해야함
그리고 카테고리 맞추기 필요
1. 시스템이 명시된 조건에서 요구된 기능을 충분히 제공하는 정도. 요구사항을 정확히 만족하는 기능을 제공하는지 평가
2. 시스템이 요구되는 성능을 얼마나 효율(비용)적으로 제공하는지
3. 시스템이 동일한 SW/HW 환경을 공유하며 다른 시스템과 공존하거나 호환될 수 있는 정도
4. 목적 달성을 위해 시스템이 사용자에게 얼마나 쉽게 사용될 수 있는지(사용자 중심의 시스템 설계 UI/UX디자인)
5. 시스템이 얼마나 오류없이 안전하게 작동할 수 있는지를 평가
6. 시스템이 얼마나 보안을 유지할 수 있는지(항상 고려해야함), 우리 시스템에서 직접 해결할 수 없는 하드웨어 등의 문제는 별도 가정사항에 정의
7. 시스템이 얼마나 쉽게 변경 및 유지보수가 가능한지 평가(빠른 변화 수용 및 개선에 중요)
8. 서로 다른 환경 간에 시스템을 쉽게 이전할 수 있는 정도를 평가
그리고 Maintainability->Reuseability, Portability->Adaptability, Portability->Replaceability의 차이 서술 가능 필요
Reuseability는 특정 시스템을 그대로 다른 시스템에 재활용할 수 있는지 ex) 회원로그인 모듈을 관리자로그인 모듈에 재활용
Adaptabilty는 다른 운영체제에서도 사용할 수 있는지 ex) 모바일에서도 웹 사이트 확인 가능
Replaceability는 모듈성이 좋아서 교체해도 아무 티가 안나는거 ex) 로그인을 카카오로그인에서 네이버로그인으로 변경
전자는 모듈 재활용, 중자는 이식성, 후자는 교체 느낌인가?QA Senario
16. QA 시나리오: 시스템의 핵심 Feature를 실현하기 위해 요구되는 모든 QA요소를 정의하는 것(품질속성을 만족시키기 위한 설계 기법 결정)
- Senario ID: 구분을 위한 번호 ex) QAS-001(Quality Ability Senario)
- Senario name: 시나리오를 간략하게 설명
- QA Type: ISO25010에서 정의한 품질 속성 하나
- Description: 시나리오 상세 설명
- Source of Stimulus: 시나리오를 발생시키는 요소
- Stimulus: 시나리오를 발생시키는 조건, 상황
- Artifact: 영향을 받거나 변화하는 대상
- Environment: 시나리오가 발생하는 환경
- Response: Stimulus에 의해 반영되는 시스템의 반응, 결과
- Response Measure: 시스템의 반응을 측정하기 위한 방법 혹은 기준
17. 시나리오를 말로 풀어서 설명하기: 사용자가 트랜잭션을 요청했을 때 시스템이 정상 운영 상황에서 시스템을 트랜잭션을 처리하고 응답을 반환해야 한다. 이때 시스템 처리의 평균 지연시간은 2초 이내여야 한다. Stimulus일 때 시스템이 Environment에서 Response를 수행하는데, Response Measure여야한다.
18. Quality Attribute Senario의 목표: 시스템에 발생할 수 있는 품질 문제점, 특정 영역에서 요구되는 품질 수준을 파악할 수 있다.
그 후 Design Decision을 통해 해당 품질 속성을 만족시키기 위한 대안을 찾고 아키텍처 설계에 반영해 나가는 과정을 거친다질의정리
Q. Useability->User Error Protection예시에 광고표기는 실수?
Q. Maintainability->Reuseability와 Portablility->Adaptabilty와 Portablity->Replaceability의 구분이 애매모호.
Q. QAS-1에서 5분이내 백업로드도 Recoverability로 봐도 되는지 아니면 Time Behavior로 봐야하는지->다른 항목으로 변경 완료
Q. QAS-2에서 Replaceability가 아닌 Adaptability로 구분한 것이 잘 한 것인지 아니면 Replaceability로 봐야하는지(통계도구)->Replaceability로 판단하여 변경
Q. QAS-1이나 QAS-2의 시나리오 명은 적절한지? 시나리오 설명을 쓴거같은데 더 축약해야할지->교재를 따라 짧게 변경
이제 3학년..