프로젝트 구현에 앞서, 먼저 프로그램의 아키텍처를 세우는 과정에서 가시적으로 표현하기위해 여러 도구를 이용합니다.
그 중 하나는, staruml인데, uml자체는 통합 모델링언어를 가리킨다.
현재까지 진행된 프로젝트 형태는,
주제: 회원등록을 하여 로그인한 사람들은 게시물을 등록하고 볼 수 있다.
첫번째 : 하나의 프로젝트에서 등록부터 게시물 관리까지 함
두번째 : 모델링2를 적용하여 요구 처리 부분과 출력 부분으로 나눠서 진행함(업무 처리: 동작 구현, 출력(뷰): 결과 출력)
세번째 : 메이븐을 적용하여 두번째와 같은 형태(처리와 출력 나누기)! maven이나 Dynamic 프로젝트나 같은 동작을 하고, 구성만 다른 형태임
두번째, 세번째는, forward를 이용하여 실제로 데이터를 넘길 때, 처리 부분에서는 출력부분의 jsp파일을 요청하고
request, response값을 넘긴다. 출력 파트에서는 받아야 하는 데이터 형태와 출력 html을 작성
네번째 : UML로 먼저 객체를 모델링하여 구조를 세우고 거기에 맞추어 기능을 구현한다(*인터페이스 개념 활용)
1. 각 패키지를 나눠서 하고자 하는 큰 그림을 그린다.
-> 보드 관리는 회원 관리에 종속된 형태이다.(한 회원에는 여러 개의 게시물을 작성할 수 있지만, 반대가 되는 상황에는 중복된 형태의 데이터를 만들기의 낭비가 심해서 직접 종속 형태로 나타낸다.
2. 사용하는 클래스를 정의한다.(및 둘의 관계도 표시하기)
Value Object인 각각의 클래스는, 필드와 메서드를 선언한다.
중간에 (1< -- 1 ) 은,
허용 가능한 인스턴스 수를 지정하기 위해 음이 아닌 정수의 포함 간격을 제공함으로써 요소 집합 의 카디널리티 ( 즉 , 요소 수)의 정의
즉, private writer로 두 클래스의 허용가능한 인스턴스를 정한 것이다. 이것으로 회원번호를 통해서 게시물을 찾을 수 있는 것! 이다.
3. 각 클래스들 간의 관계를 표시한다.
① 독립적인 VO 관점에서 DAO는 행동을 하는 주체가 되므로 (종이 되므로), DAO가 VO에 대해 종속성을 가진다.
② Member와 Board의 각각의 DAO는 회원 번호(writer)로 주고받는 관계인 ①로 인해, 서로가 필요할 때마다 쓸 수 있도록 관계가 형성된다. 지금의 관계는, 직접 연관 관계이다.
* 연관 관계: 해당 범위 외에도 지속적으로 사용이 가능한 것
* 종속 관계: 해당 범위 내에서만 사용이 가능한 것(* 위의 ②처럼, 빈번하게 쓰일 경우에는 연관 관계가 성립된다!)
* 참조 관계: 객체는 db처럼 데이터로만 호출하거나 비교를 할 수 없기에, 객체를 참조함으로써 호출이 가능하다.
지금은, -writer가 그 예시이다.(참조 관계의 예시)
마우스 오른쪽 클릭 -> format -> stereotype display -> label 로 해서, 각 인터페이스의 메서드(add -> operation 선택)를 설정한다.
operation이 보이지 않는다면, 마우스 오른쪽 클릭 -> format ->suppress operation 체크를 해제한다.
그러면 나온다.
4. 인터페이스를 이용해서 인터페이스에서 선언한 기능은, DAO에서 가져다 쓰는 형태
직접적으로 DAO에서 공통 기능을 따로 쓰지 않고, 인터페이스에서 한번에 선언함으로써 나중에 회원 등록이나 게시물 관리 기능이 아니더라도,
여러 동작에 있어서 보다 효율적인 프로그램으로 구현할 수 있다.
Github에 폴더 생성 (0) | 2021.12.06 |
---|---|
GIT 2(깃으로부터 파일 다운받기) (0) | 2021.12.06 |
GIT 1 (환경설정 및 데이터 올리기) (0) | 2021.12.06 |