UML 3-5,3-6

의존 관계와 인터페이스 의존 관계

1. 의존 관계 

• 두 클래스의 연산 간의 호출 관계를 표현한 것으로 제공자의 변경이 이용자에 영향을 미칠 수 있다.
• (제공자의 변경이 이용자의 변경을 유발)
• 이용자는 의존 관계를 통해서 제공자의 연산을 호출할 수 있다.(연관 관계: 실선/ 의존 관계: 점선)

• 단, 의존 관계에서는 필드부가 아니라 A클래스가 가지고 있는 메소드 내부에서 다른 클래스를 참고하고 있을 때 의존 관계라고 표현한다.
• 현재 test1이라는 메소드에서 B클래스를 매개변수로 참조하고 있다.
• test2메소드에서는 내용 구현 안에 C라는 클래스를 참조하고 있다. 이런 경우를 의존관계라고 한다.

 

 

 

2. 인터페이스 의존 관계

• 인터페이스 의존 관계도 동일한 내용이지만 표현이 다르다.
• op1()메소드는 인터페이스B를 참조하고 있다.
• 하지만 인터페이스B는 생성되지 않는다.(new = B가 안됨)
• 이런 경우에는 다형성을 적용해서 B라는 인터페이스를 구현한 자식 클래스인 C로 생성한다.
• B.test();를 하는 순간 B에 있는 +test()를 강제로 오버라이딩 한 C클래스에 있는 test 메소드가 바인딩이라는 것을 통해 실행된다.

 

 

 

3. 연간 관계와 의존 관계

• 메시지 전달의 통로 : 서로 다른 클래스를 참조하고 있는 관계
•  참조하는 이유: 참조하고 있는 클래스에 접근하기 위함
• 연관 관계는 A 클래스와 B클래스가 항상 연결되어 있다고 생각하면 된다.
• 다만, 의존관계로 하게 된다면 A클래스의 메소드를 실행했을 때 B클래스가 생성되고, 메소드가 종료됐을 때 B클래스는 소멸한다.

 

 

 

 

MVC 패턴

View

: 사용자 눈에 보이는 화면

Controller

: 사용자가 요청한 기능의 값을 받아오는 역할을 한다. 사용자가 어떤 값을 보내게 되면 Controller에서 받아준다. 실제로 그 기능 처리가 완료된 다음 그 결과 값을 어떤 화면에 보여줄지 화면 선택의 역할도 한다.

Model

: 데이터 처리를 담당하는 부분

1) Service : 비즈니스 로직, 데이터의 가공 처리나 트렌지션 처리를 담당한다.

2) VODTO : 클래스들 간의 값을 주고받을 때 그 값들을 보관할 보관함

3) DAO : DB라는 곳에 직접적으로 접근할 용도

1. 사용자가 기능을 요청할 때 값을 보내는데, Controller가 그 값을 받아서 간단한 데이터의 가공 처리를 할 수 있다. (View에서 전달 받아온 값들을 Controller에서 받아준다.
2. Controller에서 실제적으로 처리할 Service 값들을 보내준다.
3. Service에서 기능 처리를 하기 위해 DB에 접근을 해야 하는데, Service에서는 직접적으로 DB에 접근할 수 없어서 Dao에 값을 보내게 된다.
4. Dao가 실제적으로 DB에 접근을 한다. 그래서 값들을 DB로 보냈을 때 조회, 수정, 추가, 삭제 등의 과정을 진행하게 된다.
5. 그 결과값에 대한 값을 Dao로 다시 반환받게 된다. 만약 조회하는 기능을 요청했다고 가정하면 조회 된 객체의 결과값을 전달받을 것이고 또는 추가, 수정, 삭제를 요청했다고 가정하면 그 행의 값들을 int형으로 받아오는 과정을 하게 된다.
6. 결과값을 요청했다고 가정하면 조회 된 객체의 결과값을 전달받을 것이고 또는 추가, 수정, 삭제를 요청했다고 가정하면
7. 그 행의 값들을 int형으로 받아오는 과정을 하게 된다.
8. 처리한 결과 값을 어떤 화면으로 끌어줄지 Controller가 선택을 한 다음 해당 View에 그 결과 값을 보내는 식으로 작업하게 된다.

 

 

 

 

유스케이스 다이어그램의 결과물을 통해서 각 유스케이스 별로 유스케이스 시나리오 작성

 

---

3-6

[자바/Etc] UML (Chap03-6. 게시글 등록(중고나라)/게시글 상세조회/ 게시글 삭제)