보키_기록용

유스케이스 적기 유스케이스는 그리지않고 글로 적는다. 유스케이스는 다이어그램이 아니다. 유스케이스란 무엇인가 시스템의 동작 하나를 기술한 것 방금 시스템에 특정한 일을 시킨 사용자의 관점에서 적성하며, 사용자가 보낸 자극 '하나'에 대한 반응으로 시스템이 진행하는 '눈에 보이는' 이벤트들의 흐름을 포착한다. 사용자의 눈에 보이지 않는 동작을 전혀 기술하지 않고 시스템 안에 숨겨진 메커니즘도 다루지 않는다. 오직 사용자가 직접 볼 수 있는 것을 적어 놓을 뿐이다. 유스케이스를 구성하는 항목은 보통 두 개이다. 기본 흐름 (primary course) 사용자의 자극에 시스템이 어떻게 반응하는지 기술하는데 이때 아무것도 잘못되지 않는다고 가정한다. ex ) 판매 시점 관리(point of sale. POS) ..

기본 개념 표기 협력에 참여하는 객체와 클래스는 맨 위에 그린다. 객체는 이름 아래 밑줄이 있어서 클래스와 구분된다. Actor : 익명의 객체. 협력 과정에 들어오고 나가는 모든 메시지의 시작점이자 마지막점. 모든 시퀀스 다이어그램이 익명 액터를 갖지는 않지만, 가지는 경우가 많다. 인자(Argument) : 메세지 이름 뒤 괄호 안에 적거나, 데이터 토큰(반대쪽 끝에 원이 그려진 작은 화살표)아래에 적는다. 시간이 아래쪽으로 흐르니까 메세지는 아래쪽에 있을수록 나중에 보낸 것이다. 활성상자(Activation) : 꼭 그리지 않아도 되는 선택사항이다. 어떤 함수가 실행되는 시간을 나타낸다. 생성과 소멸 public class ShapeFactory { public Spape makeSquare() {..

클래스 표기 접근 제한자 [private : (-) / protected : (#) / public : (+)] 변수 [변수이름 : 자료형] 메서드 [함수이름 (파라미터이름 : 파라미터 자료형) : 반환값 자료형] 세부사항을 상세하게 적는 것이 유용할 때도 있지만, 자주 이렇게 해서는 안 된다. ex ) public class Dialer { private Vector digits; int nDigits; public void digit (int n); protected boolean recordDigit (int n); } 연관 public class Phone { private Button itsButtons[15]; } Phone 객체에 Button 객체가 15개 연결되어 있다. public cla..

왜 모델을 만들어야 하는가? 엔지니어는 자기 설계가 실제로 잘 작동할지 알아보려고 모델을 만든다. 여기에서 모델은 반드시 시험해 볼 수 있어야 한다는 의미가 함축되어 있다. 모델을 시험할 때 적용할 만한 기준이 하나도 없다면 그 모델은 만들 필요가 없다. '모델을 만드는 비용이 실제 물건을 만드는 비용보다 훨씬 적을 경우에 모델을 만들어서 설계를 검사해 본다.' 왜 소프트웨어 모델을 만드는가? UML 다이어그램에는 확고한 시험 기준이 없다. UML 다이어그램을 그리는 일은 소프트웨어를 작성하는 일보다 비용이 적긴 하지만, 소스코드를 바꾸기가 더 쉬운 경우도 있다. 시험해볼 구체적인 것이 있고, 그것을 코드로 시험하는 것보다 UML로 시험해보는 쪽이 비용이 덜 들 때 UML을 사용한다. 반드시 코딩을 시작..

UML(통합 모델링 언어) : 소프트웨어 개념을 다이어그램으로 그리기 위해 사용하는 시각적인 표기법. 문제 도메인(problem domain) 소프트웨어 설계 제안 이미 완성된 소프트웨어 구현에 대한 다이어그램 을 사용할 때 UML을 쓴다. 마틴파울러의 3가지 차원의 UML 개념(conceptual) 사람이 풀고자하는 문제 도메인 안에 있는 개념과 추상적 개념을 기술하기 위한 속기용 기호 어떻게 해석하느냐에 따라 의미가 달라진다. 명세(specification) 소스코드로 바꾸려고 그리는 것 구현(implementation) 이미 있는 소스코드를 설명하려 그리는 것 다이어그램의 유형 정적 다이어그램(static diagram) 클래스, 객체, 데이터 구조와 이것들의 관계를 그림으로 표현해서 소프트웨어 요..