소프트웨어는 단순히 코드의 나열이 아니라 작은 기능들 혹은 모듈들로 구성되어 있는 하나의 구조이다.
어떻게 하면 복잡하고 큰 시스템을 개별적으로 유지보수하여 진화하도록 부분들을 나눌수 있는가?이 이론의 시발점이다.
Architecutre Design
어떻게 하면 복잡하고 큰 시스템을 작은 시스템으로 분할 할 것인가
최대한 독립적으로 시스템을 분할하기
But,어려운 경우도 있음!, 모든 시스템에 걸쳐 영향이 가는 problem( _Cross cutting Problem)
Load Balancer
로드밸런서는 서버에 가해지는 부하(=로드)를 분산(=밸런싱)해주는 장치 또는 기술을 통칭합니다. 클라이언트와 서버풀(Server Pool, 분산 네트워크를 구성하는 서버들의 그룹) 사이에 위치하며, 한 대의 서버로 부하가 집중되지 않도록 트래픽을 관리해 각각의 서버가 최적의 퍼포먼스를 보일 수 있도록 합니다.
Caching, log, nonFunctional Problem
소프트웨어와 하드웨어를 매핑시킬것인가
어떤 OS 혹은 플랫폼을 이용하여 개발할 것인가
어떻게하면 분할된 여러 모듈 혹은 서브시스템들을 하나로 합칠 것인가 (Architecture style)
Well Known Architectural Styles
Pipe-Filter Style(Unix)
재사용성,범용성이 매우 높은 프로그램들(Filter)로 쪼개서 이를 연결 혹은 합쳐 기능을 구현하도록 함.
→ 우리문제를 해결하는데 사용하는 Filter가 다른문제를 해결하는데 재사용될 수 있도록 함
(단일 입력 → 단일 출력)
조합은 어떻게 ? → Pipe
ex : ls folder-name | grep -v match-string | more
앞명령어의 표준출력을 다음 필터의 표준입력으로 연결하라(|를 통해)
MVC Architecture
Model(전체시스템의 데이터처리부분), View(사용자가 볼 수 있는 부분) ,Controller(사용자가 요청하는 부분) 이때, 한 모델에대하여 여러가지 View가 있을 수 있음
Rest Architecutre (Represented Stated Transfer(not Procedure call))
리소스(정보자원) 기반 아키텍쳐로 API 를 설계하기 위한 기술
클라이언트와 서버가 독자적으로 진화 발전시킬수 있도록 하는 장점,
서버에게 명령을 통해 어떤 기능을 수행하는게 아니라 Resource를 요청으로 하여 기능을 처리하도록 하는거임
Properties
무상태성: 현재 리소스 요청에 대해서만 처리 , 이전에 무슨 명령을 써서 어떤 리소스에 대한요청이 왔는지 history를 서버에게 부담을 주지 않음 → 쿠키를 통해 이전 history를 알 수 있음
Uniform Interface
웹브라우저에서 리소스(리소스가 실재하진 않지만 있는거처럼)에대한 주소를 명령으로 쳐서 보냄(URI). 그런데 이런 주소가 사이트마다 다르고 요청 자원마다 다르게 되면 안되니 이걸 통합(Uniform)시켜놓은 API가 있음 → URI (Uniformed Resouce Idendified)
URI에 대해 더 자세한 정보를 알고 싶다면 다음을 참고하라
[더 나은 웹](https://www.betterweb.or.kr/blog/url%EC%9D%B4%EB%9E%80/)
비즈니스 목적을 달성하기 위해 사용자가 어떻게 시스템을 사용할 것인지를 알기 위함_
System이 내부적으로 어떻게 동작할 것인지에 대해 이해가위한 목적이다._
Assign Responsibility
요구분석의 결과(User Case, Domain Model)를 통해 얻은 Concept들에 대하여 각 컨셉트들에 대해 대응하는 Responstibility를 찾아내서 부여함.
Concept Connect
Use Case의 Flow of Event 각 항목으로부터 발생할 수 있는 모든 Variation에 대해 생각한다.
그런 Variation에 대해 어떤 Solution을 채택할지는 어떤 디자인원칙을 사용할지에 대해 다른데, 이는 선택의 문제이다. 여러대안들중에 고객의 요구를 가장 잘 해결할 수 있을만한 대안을 선택하는 것이 중요하다. 이는 따로 공식이 있지않고 상황에 따라 달라 많은 체험적 지식으로부터 알 수 있다.
보통 객체별로 책임을 완전히 분리하여 해당 일을 전문적이게 하는 객체에게 일을 넘기는 방식을 지향한다. 하나의 객체가 여러가지의 책임을 가지면 확장성이 매우 떨어진다.
확장성은 보통 기능이 수정,추가될때 코드에 전체적인 변화량에 의해 판단되어진다. 어떤 기능을 수정하게 될때, 코드의 전체적인 부분에 수정이 가해지면 확장성이 떨어진다고 볼 수 있다.
문서화
선택한 Solution에 대해 reasoning process를 다큐먼트해야함
(설계자가 고려했던 대안들에 대해 충분히 문서화시켜서 결론적으로 왜 이 Solution을 채택하게 되었는지를 문서화시키는 것이 중요)
Object Sequence Diagram 과 Class Diagram
Object Sequence Diagram을 그린후에 Responsibility 가 있는 Object들끼리 어떤 상관관계가 있는를 그림으로 나타냄(Class Diagram)
OSD: 시스템 내부에 동작한 Object들이 어떻게 연결되어 있는지에 대한 그림
테스팅의 목적은 어떻게하면 적은 비용으로 가장 많은 오류를 검출할 수 있도록 테스트를 할 것인가?이다.
그리고 어떠한 테스팅을 하냐에 따라 얼마나 오류를 적은 비용으로 잘 검출했는지가 달라질 수 있음을 유의해야 한다. 단순히 많은 테스트케이스를 검사했다고 test coverage가 높다고 말할 수 가없다.
어차피 테스팅을 아무리 잘한다해도 우리는 시스템이 어떤 오류도 없이 잘 돌아갈 수 있음을 보장할 수 없다.
결국 체계화되고 잘 설계된 테스트케이스를 선별함으로써 굳이 테스트 해보지 않아도 선별된 테스트케이스(critical test)를 통과하면 자동으로 그 테이트도 통과할 수 있음을 기대하고 어떤 테스트를 수행할지 우선순위를 정해야한다.
Heuristic(경험적 지식) for acheiving high coverage
black box testing( 코드를 직접 보지않고도 생각해낼 수 있는 테스팅, 입력데이터에 초점)
Equivalence testing
입력데이터 종류와 범위를 미리 안다고 치면,데이터를 어떤식으로 뽑아야 오류를 검출해낼 수 있는지를 알 수 있음
모듈의 명세서를 통해 해당 기능에서 어떤 데이터를 받는지 확인한 다음,해당 데이터의 범위 경계선,밖을 기준으로 데이터를 선별해내는 방식이다 .
보통 두 그룹으로 데이터를 나눔,해당 명세서에서 입력받는 데이터의 그룹에 속한 데이터들과 속하지 않는 데이터들
Boundary testing
입력데이터들의 경계값들에 초점을 맞춤
white-box testing(코드를 정확히 이해하고 코드테스팅)
Control- flow testing
소스코드의 제어흐름의 이동경로 테스트
State based testing
객체지향적인지를 테스트하는 기법