ComputerScience/Software Engineering (26) 썸네일형 리스트형 소프트웨어공학 - 22. Exception Handling 1. exception handling - 프로그램 개발중에 발생하는 예외 event를 처리하는 것을 말한다. - c언어처럼 예외처리 메커니즘이 제공되지 않는 환경에서도 물론 if case로 처리할 수 있긴하다. - 위의 코드는 파일을 읽고 처리후 파일을 닫는 코드이다. - 파일 열기가 실패했을때, 파일의 size를 알아내기가 실패했을때, 등의 여러 예외 상황에 대한 대처가 부족하다. - 따라서 예외 상황을 다 분기하면 코드가 상당히 읽기 어려워진다. - 즉 정상적인 flow과 비정상적인 예외 상황을 처리하는 flow간의 분리가 잘 안되어있다. - 그래서 exception handling이 꼭 필요하다. - catch문을 통해 flow의 분리가 명확해졌다. (+가독성 향상) - 이번에는 함수가 call .. 소프트웨어공학 - 21. Code coverages for white box testing 1. Code coverage - test suite을 사용해서 테스트를 했을때 소스 코드의 어느정도까지 커버가 가능한가? 2. function coverage - test suite을 실행했을때, 프로그램을 구성하는 모든 function들의 실행을 커버하는가? 3. statement coverage - 코드의 각 line들이 다 한번씩 실행 되었는가? - node coverage라고도 불린다. - 위같은 소스코드에 대해 statement coverage를 수행해보자. - 두개의 test case로 test suite이 구성되어 있을때, TC1은 s1,s2,s3까지밖에 커버를 못한다. 반대로 TC2는 모든 statement의 실행을 수행했다. - 하지만 두 테스트 케이스로 구성된 test suite은 모.. 소프트웨어공학 - 20. Verification and Validation (V&V) 1. Verification and Validation (V&V) - 소프트웨어의 개발 프로세스에서 우리가 의도한 대로 잘 만들어지고 있는지 리뷰와 조사를 통해 검증하는 것을 verification이라고 한다. - 검사, Inspection은 요구사항, 디자인, 코드 등의 산출물들을 점검하는 것을 말한다. - inspection은 프로그램이 실제로 구동되어야 검사할 수 있는 항목에 대해서는 점검이 어렵다. - 개발 산출물들이 requirement를 잘 충족하고 있는지 검사하는 것을 Validation이라고 한다. 2. Testing - 소프트웨어가 해야할 일들을 잘 수행하는지 testing을 통해 성취된다. - 주 목적은 defect를 탐지하는 것이다. Development testing - 개발 단계에.. 소프트웨어공학 - 19. Test-Driven Development 1. Unit Testing - 코드가 옳다는 것을 검증하는 방법이다. - 유닛 테스트는 divide and conquer 전략을 따른다. 전체 시스템의 유닛들이 잘 동작함을 검증함으로써 전체 시스템의 신뢰를 높인다 - 테스트를 수행하는 코드인 test suite를 만들어서 유닛 테스트를 수행할 수 있다. - 테스트 코드를 만드는 일이 오히려 개발시간을 늦추는 일처럼 보일 수 있으나 추후 유지보수와 디버깅이 매우 쉬워지기 때문에 (프로젝트가 클수록) 훨씬 이득이다. - 테스트 대상인, unit은 class가 될수도 있고 class들로 구성된 모듈이 될 수도 있다. 그 테스트를 수행하는 코드가 unit under test이다. - 테스트를 수행하도록 unit test code를 호출하는 주체를 driver.. 소프트웨어공학 - 18. SOLID inheriance- 지난시간 GRASP에 이어서 이번 장에서는 OOP 설계 원칙 중 또 하나인 SOLID 설계 principle을 살펴보자. 1. Design Smell - 소프트웨어, 시스템이 잘못 디자인 되었을 때, design smells라고한다. - Rigidity, 경직성 : 시스템 변경이 어렵다. 변경하려면 건드려야할 부분이 너무 많다. - Fragility, 취약성 : 한군데 변경하면 잘못되는 부분이 많은 취약한 상태 - immobility, 부동성 : 재사용성이 떨어짐, 너무 엉켜있어서 코드의 이동성이 떨어짐 - viscosity, 점착성 : 초기 디자인대로 시스템을 확장하기 너무 어려운 경우 - needless complexity, 불필요 복잡성 : 설계가 너무 불필요하게 복잡하다. -.. 소프트웨어공학 - 17. GRASP 1. GRASP - General Responsibility Assignment Software Patterns - 객체 설계에 대한 9가지 원칙을 제시한다. - 전형적인 OOAD의 순서는 "1. 요구사항 파악 -> 2. domain model 생성 -> 3. design model 생성" 이다. - grasp은 구체적으로 3단계에서 "class에 속성을 부여"하고 "서로 관계를 맺는" 작업의 가이드라인을 제공한다. - 즉 domian model을 보고 design model을 만든 원칙을 제시한다. 2. Responsibilities - class의 책임을 정의한다. knowing - 그 클래스는 어떤 정보를 알고 있어야 하는가? - 관련있는 객체는 누구인가? (다른 객체들의 정보는 어디까지 알고 있는.. 소프트웨어공학 - 16. UML Communication Diagrams 1. interaction diagram 종류 - 우리가 이제까지 배운 sequence diagram은 interaction을 표현하기 위한 방법이였다. - 표기법만 다른, 동일한 목적과 역할을 수행하는 diagram도 있다. 서로 정확하게 대응이 가능하다. - communication diagram이라고 한다. Interaction diagram의 한 종류이다. - timing diagram이라고 한다. 역시 Interaction diagram의 한 종류이다. - 각 개체의 state를 고려한 interaction을 표현할 때 유리하다. - activity diagram과 sequence diagram을 합한 모습이다. - Interaction overview diagram이라고 한다. 역시 Inter.. 소프트웨어공학 - 15. MVC Architecture pattern 1. Model View Controller Pattern - 소프트웨어 설계 패턴이다. - Model : 데이터가 저장되거나, 비지니스 로직이 돌아가는 부분 - View : 화면에 직접 보이는 GUI 파트, 그림을 그리는 것에만 집중 - Controller : 사용자와 UI의 상호작용을 정의하는 부분. 사용자에 요청에 따라 model값을 변경하는 api를 요청한다. - 이렇게 세 부분으로 프로젝트의 구조를 구분하여 개발하는 것을 말한다. - 하위 레이어인 Non-UI Layer는 절대 상위 레이어에 의존하지 않는다. - UI Layer가 하위 Non-UI Layer로 interface를 통해 접근한다.이 의존은 어쩔수 없는 것이지만 그 반대의 경우의 의존 관계가 있어서는 안된다. - 그래야 자주 UI의.. 이전 1 2 3 4 다음
