액터4 객체지향의 사실과 오해 - 기능 - 이 글은 조영호의 객체지향의 사실과 오해를 기반으로 작성되었습니다. (가능하면 꼭 읽어보는것을 추천드립니다.) - 유스케이스 기능적 요구사항이라는 말을 들어본적이 있을것이다. 기능적 요구사항이란 시스템이 사용자에게 제공해야하는 기능의 목록이다. 시스템은 사용자의 목표를 달성하기 위해 기능들을 제공하는데 사용자가 시스템에 작업을 요청하고 시스템은 이 요청을 처리하여 응답한다. 이러한 과정은 사용자가 목표를 이루거나 에러가날 때까지 계속된다. 유스케이스는 사용자의 목표 달성을 위해 사용자와 시스템간의 상호작용의 흐름을 텍스트로 정리한것이다. 시스템이 제공해야 하는 기능 목록을 모두 만족하면 사용자의 목표를 이룰 수 있는데 왜 굳이 유스케이스 라는 것을 따로 작성해야 하는가? 시스템이 제공해야하는 기능 목.. 2021. 8. 27. UML - 유스 케이스 - 다이어그램과 수준 - 이 글은 UML Distilled (마틴 파울러)책을 기반으로 작성하였습니다. - https://en.wikipedia.org/wiki/Use_case#Cockburn_style - 유스 케이스 다이어그램 UML의 유스케이스 다이어그램이 유용하긴 하지만 필수적인 것은 아니다. 따라서 유스케이스 작업에 필요이상으로 몰두하면 본질을 넘어서 tool 사용에 집착하는것이 된다. 그러므로 유스케이스 다이어그램보다는 유스케이스 내용의 텍스트 작업에 정성을 쏟아야 한다. 유스케이스 다이어그램은 시스템의 영역을 나타내고 외부 세계와의 교류를 보여준다. 유스케이스 다이어그램에는 액터와 유스 케이스가 있으며 이 둘의 관계는 다음과 같다. 어떤 액터가 어떤 유스 케이스를 수행하는가? 어떤 유스케이스가 다른 유스 케이스를.. 2021. 2. 11. 설계원칙 - SOLID(SRP) - 이 글은 로버트 C.마틴의 Clean Architecture를 기반으로 작성되었습니다. (가능하면 책을 읽어보는것을 추천한다.) - 개요 단일 책임 원칙은 가장 많은 오해를 사고 있는 원칙이다. 이름만 보면 마치 하나의 모듈은 하나의 일만 해야하는 것처럼 느껴진다. 하지만 이는 오해이다. 하나의 모듈은 하나의 액터(사용자 및 이해관계자)에 대해서만 책임져야 한다. 모듈이란 보통의 경우엔 소스파일이다. SRP를 위반하는 원칙들을 살펴보면서 SRP를 이해해보자. - 징후: 우발적 증복 급여 어플리케이션에서 Employee 클래스가 있고, 해당 클래스에서 calculatePay(), reportHours(), save() 메소드를 제공한다고 해보자. 이 클래스는 SRP를 위반한다고 할 수 있는데, diag.. 2021. 2. 10. UML - 유스 케이스 - 개요와 내용 - 이 글은 UML Distilled (마틴 파울러)책을 기반으로 작성하였습니다. - 유스 케이스 유스 케이스는 시스템의 기능적인 요구사항을 잡아내는 기술이다. 유스케이스는 시스템과 사용자간의 교류를 기술한다. 유스 케이스를 곧바로 판별해내는것은 사실 어려운일이다. 보통은 시나리오를 생각해본 뒤 유스케이스를 식별한다. 시나리오는 사용자와 시스템간의 교류를 단계적으로 나타낸것이다. 예를 들어 온라인 쇼핑몰에서 물건을 산다면 시나리오는 아래와 같다. 고객은 상품 목록을 보고 원하는것을 선택하여 장바구니에 담는다. 물건을 구매하기 위해 배송지 및 신용카드 정보를 기술한다. 시스템은 신용카드 승인을 확인하고 물건 구매 확정을 한다. 그리고 그 결과를 이메일로 발송한다. 위의 시나리오는 개발자가 구현하기 좋은 전.. 2021. 2. 10. 이전 1 다음
