5-1. UML (클래스 다이어그램)

요구를 추출하고 도메인 영역 안에서 분석하고 그걸 가지고 명세를 해야한다.

→ 즉, 모델링을 해야 한다.말로 한걸 모델링해서 도면이 나온다

의사소통이 쉽고 오해가 안생긴다

자바, c++은 개발하는 언어, 코딩하는 언어이고 모델링을 하는 언어가 바로 uml

요구사항을 찾고모델링 하기 전에 uml을 배우는 것

Uml : unified modling langauge라는 것으로 언어, 컴퓨터와 의사소통이 아닌 사람들 사이의 의사소통에 사용

소프트웨어 개발에 참여하고 있는 이해 당사자들의 요구사항이 맞는지, 사용자와 요구사항이 맞는지, 설계하는 사람과 요구분석 사이의 의사소통, 코딩하는 사람과의 의사소통 등에 사용

• Uml로 모델링하면 도구로 자동화도 가능하기에 uml의 결과는 컴퓨터가 이해해서 코드로 만들어낼 것. 컴퓨터랑도 의사소통하지만 자바, c와 같은 것과 달리 전과정에 참가하는 사람들이 주 목적임 컴퓨터랑도 의사소통하기는 하지만 주는 사람~

소프트웨어의 문제점

1. 소프트웨어가 다루는 문제의 복잡성
2. 잦은 변경

모델 기반 기발의 이점

말로 되어있는걸 시각화해서 바꾼다 : 모델링한다

이걸로 설계, 구현, 테스트하는 모든 과정에서 모델링을 해야 한다 코딩보다 상위언어

• 프로그래밍 언어로 바로 코딩하기는 어렵다, 코딩 가지고 의사소통하기 어렵다 그래서 모델 기반으로 개발할 것

• 시각화(visualization) :

  한 장의 모델링 다이어그램은 백 마디의 말보다 가치가 있다

  말로 되는 것보다는 훨씬 이해하기가 쉽고 오해도 적고 의사소통이 쉬우며 일반인이 봐도 이해가능하다, 사용자도 이해 가능

• 이해도(understanding) :

  다양한 종류의 다이어그램을 활용하여 시스템을 여러가지 관점에서 분석할 수 있다

  이해하기도 쉽다, 다양한 종류의 모델링을 할 건데이런 다이어그램을 그릴 것이고 다양한 다이어그램을 활용해서 보면 개발하고자 하는 시스템을 여러가지 관점에서 볼 수 있다, 이해하기 쉽다

  Ex) 도면을 전기 도면 등 여러가지 도면을 쓴다

• 일관성(consistency) :

  모델을 다양한 다이어그램과 요소는 서로간의 일관성 체크가 자동으로 가능하다.

• 정확성(correctness) :

  분석/설계 단계에서 가능한 검증으로 문제를 조기에 발견할 수 있다

  시스템이 일관되어야 하는데 여러 관점의 다이어그램을 그리게 되면 일관성이 다르면 문제가 있는지 체크하기에 정확한지 체크도 가능

• 의사전달(comunication) :

  이해 당사자의 이해도 차이와 프로젝트 진척도에 따라 추상화 수준의 차이를 두고 설명할 수 있다

  코딩해서 보여주는 것보다 의사소통이 쉽고 사용자와 의사소통 할 때 쉽다

• 이해당사자간의 서로 합의하기가 쉽다

→ 모델링을 기반으로 구현할 것

또 다른 이점은?

모델 = 코드

모델을 작성해놓으면 그게 바로 코드가 됨. 툴로 자동으로 만들어주는 툴이 존재한다.

→ 모델로부터 코드 생성을 자동화한다

cf. MDD(model driven development) : 모델을 만들면 자동화해주는 도구

→ 생산성을 높일 수 있다

모델링

• 도메인 지식을 최계화하는 과정
• 중요한 도메인 개념과 특성 관계를 파악하여 다이어 그램으로 정형화

요구분석 과정에서 도메인분석을 하게 되는데 도메인 개념을 찾아내면 시각화해주면서 도메인 지식을 최계화한다.

• 요구분석단계부터 모델링을 함 → 도메인 분석 이후 기능적 모델링 / 분석단계에서 동적, 정적 모델링 후 분석단계(사용자, 도메인 관점)가 끝나고→ 설계단계에서는 개발 관점으로 쓰게 된다.
• 모델링 할 때 다양한 관점으로 볼 수 있다고 했었는데 무슨 기능을 가져야하는지, 우리가 개발하려는 시스템의 전체 구조가 어떻게 되는지, 실제로는 어떤식으로 상호 동작을 어떻게 하는지 등을 볼 수 있다

모델링이 개발자에게 주는 도움

• 응용문제를 이해하는데 도움을 줌
• 개발팀원들 사이에 응용문제의 공통개념으로 대화하게 하고 개선시킴
• 파악한 개념을 사용자와 고객에게 전달할 때 도움을 줌
• 후속작업 즉 설계, 구현, 테스팅, 유지보수에 개념적인 기준을 제공
  • 의사소통할 수 있고 결국 전체 라이프사이클에서의 베이스라인이된다

모델링과 모델

개발하려는 시스템이 있을 건데 나는 일단 모르고 이걸 사용자한테서 도메인분석하고 이걸 모델링해서 모델들이 나오게 되고 이 모델이 개발하려는 시스템을 보여주기에 이걸 결국 구현할 것 -> 개발하려는 시스템이 나오게 된다 : 모델 기반 개발

소프트웨어 모델링

전 과정에서 모델링이 들어가는데 앞부분 특히, 요구사항 찾고 분석하고 설계하는 과정에서 모델링이 들어간다.

• 요구사항 정했을 때에는 요구사항 모델, 사용자가 원하는 게 무엇인지를 가지고 모델링(사용자 입장에서 기능적인 what)
• 분석하면 분석 모델이 나온다(결국 시스템적으로는 우리가 해야하는 것은 무엇인지, 시스템에 무엇이 있어야 하는지, what)

여기까지는 도메인 개념, 개발 플랫폼 개념이 안들어가고 사용자 관점에서 해야하는게 무엇인지 무엇을 개발해야하는지를 모델링

• 설계하면 설계모델(설계단계가 되면 플랫폼, 디비, 언어가 정해지기 때문에 이 what을 어떻게 구현할 지, how, 여기서는 실제 개발 플랫폼개념이 나오게 됨)
• 이걸로 구현하면 시스템이 나오게 될 것

소프트웨어개발의 많은 부분을 모델링이 차지하고 있다.

UML(Unified Modeling Language)

프로그래밍 언어가 아니라 모델링하는 언어

• 객체지향 소프트웨어를 모델링하는 표준 그래픽 언어

cf.

객체지향 대가 세명 있었음

각각이 자신들의 방법론을 가지고 있어서 각자 가고 있었는데 객체지향이 많이 쓰게 되니까 우리 합치자! -> UML

초창기 우리나라는 유행을 타다보니 다쓰다보니 쓸대없는 문서들이 많이 나오게 되어 필요한거만 그때그때 쓰자로 바뀌게 됨

• 개발 단계 별로 주로 사용되는 다이어그램이 존재

유스케이스 다이어그램

클래스 다이어그램(반드시 필요, 구조, 일하는 모습은 모름), 객체 다이어그램(객체입장에서 그린 것), 상태 다이어그램(실시간 시스템에서 중요), 활동 다이어그램(동적으로 인한 것), 상호작용 다이어그램(은행예제처럼 서로 상호작용하는 거 보고 싶을 때)

클래스 다이어그램은 분석에서도 나오고 설게에서도 나온다 -> 같은 건데 분석단계에서는 사용자의 도메인 관점에서 클래스를 찾는 것이고 설계는 실제로 어떤 구현기술을 구현하냐에 따라 달라짐 구현의 관점으로 바뀐다고 보면 됨.

• 소프트웨어 모델링에서 모델링은 전과정에서 영향을 준다. 요구상황에서는 유스케이스, 시퀀스 다이어그램이 주로 나오고 분석 후에는 클래스 다이어그램 등등 ,설계로 가게 되면 다양한 다이어그램들이 구체적으로 기술에 맞춰서 다이어그램이 많이 나오게 된다. 그거에 맞춰서 코딩을 하면되고 그 모델은 결국 테스팅까지 와서 테스트하는 사람도 제대로 구현했는지 보고 판단

요구사항단계에서는 유스케이스 뿐만 아니라 시퀀스, 클래스도 나오긴 하지만 주된 거는 유스케이스

분석단계에서는 클래스, 엑티비티, state 차트 다이어그램 등등이 되고 설계 단계에서는 더 구체화되고 (논리적인 구현의 단위)컴포넌트 다이어그램, (하드웨어에 어떻게 배치될 것인지)배치 등등이 존재

구조 다이어그램

행위는 모르고 구조는 아는 다이어그램

• 클래스 다이어그램(구조적 관점) : 시스템을 구성하는 클래스 표현
• 객체 다이어그램(객체) : 시스템을 구성하는 객체
• 패키지 다이어그램(클래스나, 컴포넌트, 유스케이스 등등을 관련있는 걸 묶어놓는 것) : 많은 수의 모델 요소들을 패키지를 이용하여 조직화함
• 컴포넌트 다이어그램(논리적임, 어떤 인터페이스가 들어가는지 등등) : 시스템을 구성하는 논리적 컴포넌트 표현
• 배치 다이어그램(실제 디비는 머쓸 것인지 서버는 뭘 쓸 것인지 등등…) : 물리적 컴포넌트를 표현

행위 다이어그램

• 유스케이스 다이어그램(요구사항 찾을 때 많이 사용함) : 시스템의 외부요소와 기능적 요구사항을 엑터와 유스케이스로 표현
• 상태다이어그램(실시간 프로그램에서는 많이 사용하지만 우리는 안배움) : 개별 대상 동적 행위를 상태와 전이로 표현
• 활동 다이어그램 : 개별 대상의 동적 행위를 활동으로 표현(순서도 같은 것, 객체 하나가 일을 어떻게 하는지),
• 시퀀스 다이어그램 (여러개의 객체가 시간순으로 어떻게 하는지) : 상호작용을 구성 요소간의 시간적 순서에 따른 메세지 전달로 표현

기능적 관점, 구조적 관점, 동적 관점

• 기능적 관점(유스케이스 다이어그램,사용자가 시스템을 사용하는 사례)
• 구조적 관점 : 시스템의 전체 구조를 보는 클래스 ,컴포넌트, 배치 다이어그램이 해당
• 동적 관점 : 일하는 동적인 것을 보는게 상태, 엑티비티 다이어그램, 활동 다이어그램, 여러개의 객체간의 인터렉션보는 거 시퀀스 다이어그램

클래스 다이어그램

• 유스케이스, 시퀀스, 클래스가 제일 중요함
• 시스템을 구성하는 클래스들과 이들간의 상호간의 관계를 표현함
  • 클래스의 연산과 속성을 표현
• 시스템 구조적 측면, 정적인 측면을 보는 것
• 분석 클래스 모델링과 설계 클래스 모델링에도 사용됨 : 이 때 표현된 깊이나 방향은 다르다

클래스

속성

• 클래스가 나타내고자 하는 객체들의 정보와 상태를 표현하는 변수

가시성

클래스의 외부로부터의 속성에 대한 접근 허용여부를 지정

이름

속성이 표현하는 객체의 정보/ 상태를 의미하는 명사

다중성

동일한 이름으로 복수개의 속성 값이 있음을 표현

초기값

객체가 생성될 떄 속성에 대한 초기값

타입

Uml타입을 써도 되고 정한 언어의 타입을 써도 된다. 그냥 서로 이해할 수만 있으면 된다

사용자 정의 타입도 존재

«» : streo type, UML과 이미 만든거에는 없는데 새로 만들어서 부가정보를 적고 싶을 떄

• 제약사항은 {}안에다가 표시

툴을 쓰면 자동으로 generate되지만 매치되는 건 알아야 한다

클래스범위 & 인스턴스 범위

1. 인스턴스 범위의 속성 : 객체 별로 의미가 있고 적용되는 속성
2. 클래스 범위 속성 : 클래스 자체에서 의미가 있는 속성, 언더바로 표현, static

객체는 언더바로 표시하며 실제 값, 상태를 가지고 있음

윈도우 타입의 객체가 세개가 있고 점선으로 의존관계를 알려준다. 스테레오 타입은 그냥 필요하면 만들면 된다. New 연산자 쓰면 된 것

객체가 세개인데 객 개체마다 맴버변수를 가지고 있지만 totalwindowcount인 static 변수는 안가지고 있으며 얘는 따로 영역에서 하나 만들어져있음

유도속성

• 값이 다른 속성이나 다른 클래스와의 관계에 의해서 결정될 수 있는 속성
• /로 표시
• 다른 속성값들을 바탕으로 계산될 수 있으므로 필수적이지 않음
• 유도속성 사용 시 추가적으로 유도 속성의 무결성을 유지하는데 주의를 해야 한다

Width가 없어도 함수로 쓰는 경우에는 계산해도 되고 아니면 유도 속성을 만들어서 게터만들고 update함수를 만든 뒤 왼쪽에 포지션이 달라질 때마다 update하도록 할 수도 있다

조회하는 일이 많으면 왼쪽, 갱신을 자주하면 오른쪽으로!

이떄 무결성을 유지해야 한다 즉, 바뀔떄마다 update해줘야하고 아니면 오류를 못찾게 된다.

클래스의 속성들을 밀접한 관련성이 있어야 한다

관련성이 낮을 경우 즉, 클래스의 응집도가 낮을 경우에는 관련된 속성끼리 묶어서 클래스를 분할해야 한다!

릭의 기타가게에서 한건데 클래스는 관련있는 거끼리 해야하고 하나의 일만 해야 한다!

도서정보를 보면 정보가 두가지 들어있다 : 이름출판사명은 안바뀌는 거지만 구매일 파손여부 대출가능여부는 바뀌기에 분리해야 한다.

속성의 표현 수준은 개발단계에 따라서 달라진다

What의 관점 → how의 관점

• 분석단계 : 기능적 요구사항을 표현할 수 있을 정도로 클래스의 속성을 정의 - what의 개념으로 사용자와 도메인 관점에서 무엇을 할 것인지
• 설계단계 : 소스코드가 자동으로 생성될 정도로 모든 것을 구체적으로 명확하게 기술해야 함 - how의 관점으로 기술관점이 되어 어떻게 구현할 것인지

속성이든 연산이든 클래스 다이어그램은 분석단계와 설계단계에서도 쓰일 예정

도메인에서 의미있는 이름을 쓰고 설계 단계에서는 플랫폼, 기술 관점에서 쓰일 것 전자는 what, 후자는 how 개념!

연산

• operation, 객체의 행동

가시성

클래스 외부로부터의 연산에 대한 접근의 허용 여부를 지정

이름

연산을 구분하기 위한 이름으로서 주로 동사형 – overloading이 가능 – 인자의 개수와 타입이 다르면 동일한 이름의 연산을 정의하는 것이 허용됨 인자방향

호출자와 피호출자 간에 인자 값의 전달 방향을 뜻함 – UML에서는 in, out, inout의 세가지 유형을 정의함 인자 이름

인자 이름은 인자들 중에서 고유한 이름을 가지며 전달되는 값의 의 미를 표현하는 용어를 사용하는 것이 바람직하다. 인자 타입

전달되는 인자 값의 타입 – UML 기본 타입, 사용자 정의 타입, 프로그래밍 언어의 타입 반환타입

연산의 수행 후에 반환되는 값의 타입을 지정

클래스 수준의 연산

• 클래스 범위의 연산 : 인스턴스 범위의 속성을 접근하지 못하고 클래스 범위의 속성만 접근이 가능한 연산
• 밑줄로 표시

• 앞에 +는 Public이고 반환형은 콜론 뒤에 표시
• 매개변수를 보면 in,out,inout이 앞에 붙어있는 경우가 존재, in은 들어오기만 하고 나가지 않는 것, 매개변수로 포인터를 주는 경우가 있는데 포인터에 값을 반환받을 수도 있음. Int는 들어오는 값이지만 int*하면 메소드 안에서 값을 내보낼 때 값을 바꿀 수 있다.(굳이 구분을 안해도 되기는 한다)
• 그 때는 in이고 포인터를 쓰면 주소값을 주기 떄문에 역참조해서 값을 바꿀 수 있게 된다 내보낼 수 있다. 그게 out,두가지 역할 다할거면 inout, 기본은 in ex) Scanf에서 포인터를 주는 이유도 변수에 해당하는 내보내는 거에 값을 담아주기 때문에 값을 내보내는 것, &를 쓰는 것
• 매소드의 원래 의도는 정보를 넘겨주는 것이고 정보가 in이지만 포인터를 통해 값을 내보낼 수가 있다. 매개변수를 가지고 out역할을 하는 경우도 존재하기에 만들어놓은 것

uml 표기법, 자바코드로의 변환 이런 거는 할 줄 알아야 한다. 인터페이스 개념 이해하는 거 중요

추상연산(abstract)

추상 메소드

자바의 경우에 바디가 없는 메소드가 존재 , 구현이 불가능한 연산

추상 클래스

객체를 실체화하지 못하는 클래스

• 추상연산과 추상 클래스는 italitic으로 표시
• 추상 메소드를 가지고 있는 추상 클래스도 이탤릭체로 표시

연산의 표현 수준은 개발 단계에 따라서 달라진다.

분석 단계에서는 구현할 떄는 모르지만 point로 일단 타입 지정, 초기단계에는 한글로 적어도 상관없음

설계단계로 가서 언어가 정해지면 가시성, in/out이런 거 쓸 수 있으면 쓰면 된다. Void도 마찬가지 있으면 사용

속성에 in이 있는 건 값이 바뀔 수 없으므로 final로 들어오게 해서 내부에서 수정못하게 할 수도 있다. 상수처럼~ 이렇게까지 안해도 되긴 함

✅클래스 다이어그램의 관계(중요)

• 클래스 다이어그램에서 클래스 무엇이 있는지도 궁금하지만 객체지향은 객체 + 객체로 여러 객체가 같이 일하기 떄문에 클래스 사이에 어떤 관계가 분명 존재할 것

관계들을 구분해서 알면 되고 의미나 코드로 변환을 알면 된다

1)연관관계(association)

디비에서 erd 개념을 모방해서 가져오면 됨

• 두개 이상의 클래스 간의 관련성을 의미
• 관련성의 정확한 의미는 관련된 두 클래스에 따라서 달라진다.
• 연관 관계의 의미를 연관의 이름(association name)이나 role name(역할)을 이용해서 구체적으로 표현할 수도 있다.(role name을 더 많이 사용하는 편)

연관관계는 그 클래스가 나타내는 객체들 사이의 메세지 전달의 통로 역할을 한다

• 연관관계가 없는 객체의 기능(메소드 호출)을 사용할 수 없다
• 연관관계가 있는 객체의 메소드 호출이 가능하다

ex) 수업이라는 클래스는 담당교수를 조회하고 수강학생 수와 수업시간을 조회한다. 이런 기능들을 가지고 있고 교수는 조교와 연관관계가 있고 학생은 수업과 교수에 연관관계가 존재

수업은 다 연관관계가 있으며 학생은 조교의 기능을 호출할 수 없고 학생은 조교의 기능을 호출할 수 없다

학생은 해당 교수의 전공과 성격을 조회할 수 있고 교수는 학생의 성적과 학년을 조회할 수 있다

교수와 학생을 수업을 다 호출할 수 있고 수업도 교수와 학생을 부를 수 있다

단, 조교 학생은 불가

객체 다이어그램을 보면 성실한 조교라는 객체가 진짜로 존재함(주로 밑줄을 그어줌) 객체니까 실제 일을 하기에 메소드 호출이 가능하지만 조교과 학생은 서로 호출 불가

→ 클래스 다이어그램 그린 후 위의 방식대로 객체 다이어그램을 메소드 학생 조교 호출 가능하도록 그리면 일관성에 문제가 생기는 것

• 연관관계는 맴버변수로 표현

  

• 연관관계의 방향성

  • 방향성이 없다면 조교는 교수를 알고 조교도 교수를 알기에 양 쪽 모두 맴버변수로 가지고 있어야 한다.
  • 방향성이 있다면 나가는 화살표를 가지는 클래스 쪽에서만 맴버변수로 가질 수 있다.
  • 연관관계의 방향성은 메세지 전달의 방향을 의미함. 반대는 불가능

  

연관관계의 다중성

다중성 : 관계를 맺을 수 있는 실제 상대 객체의 수, multiplicity

• 다중성은 클래스 다이어그램에 표시되지만 실제로는 연관되는 상대 댇체의 수에 대한 제약
• 숫자가 없다면 1로 보면 된다

• 다중성은 배열로 표현할 수 있다

  

  • 관련된 객체 수에 대한 제약은 단순히 배열의 크기만으로는 보장되는 것이 아니기에 추가적인 구현이 필요하다.

  

다중연관

동일한 클래스 두개가 연관관계가 여러개 있는 경우가 존재

ex) 교수와 학생 사이에는 수업관계와 면담하는 관계도 존재

• 다중연관관계가 사용되는 경우에는 구분하기 위해서는 연관 이름이나 역할이름을 반드시 써줘야 한다

• 각각의 연관관계에 대해서 맴버변수를 선언해주면 된다.

1-2) 집합/ 포함관계

연관관계 중에서 특별한 관계로 좀 더 강한 관계를 의미

• 두 객체 간의 포함/소속의 의미를 클래스 수준에서 포현된 것
• “전체는 부분으로 구성된다” “부분은 전체의 부분이다.”
• has a 관계이지만 좀 더 강한 has a 관계
• 포함관계가 집합관계보다 더 강한관계

• 그냥 선그으면 연관이지만 마름모가 있으면 집합/포함이고 마름모가 채워져있으면 포함, 비어 있다면 집합관계

  

ex) 컴퓨터는 본체와 프린터를 가진다

전체 부분관계인데 컴퓨터는 본체가 없으면 의미가 없음

포함관계는 life cycle을 같이 하지만 집합 관계는 lifecycle을 같이 하지 않는다.

ex) 프린터기는 lifecycle을 같이 하지 않는다. 본체는 없으면 컴퓨터가 죽음. Life cycle이 동일

• 연관관계이기 때문에 방향성, 다향성, 다중성, 이름/역할 다 사용 가능

1-2-1) 집합관계(aggregation)

공유집합(shared aggregation)관계라고 부르기도 하는데 부분객체가 전체 객체들 사이에서 공유될 수 있음

Ex) 프로젝트 하나는 하나 이상의 멤버를 가지지만 멤버도 프로젝트를 여러개 가질 수 있음

라이프사이클을 같이 하지 않기에 프로젝트가 사라져도 맴버는 존재하며 맴버는 두개의 프로젝트에 들어갈 수 있다

1-2-2) 포함관계(composition)

부분객체가 오직 하나의 전체객체에 포함될 수 있음

ex) 프로젝트는 팀으로 구성되고 팀은 멤버로 구성되는데 프로젝트와 팀은 포함관계인데 맴버는 여러개의 팀에 들어갈 수 있음. M2는 team1, team2에 다 들어갈 수 있지만 team1은 project1,project2에 둘다 들어갈 수 없음. 포함이니까 하나에만 들어가야 한다

• 물리적으로 같은 lifecycle을 가질 경우 사용
• 물리적인 객체들 간의 관계에서 주로 많이 발견되는 관계

ex) 문, 모터는 이 엘리베이터에만 속하고 엘리베이터가 없어지면 의미가 없어 진다

2) 일반화관계(generalization)

• Is a 관계로 한 클래스(상위 클래스)가 다른 클래스(하위 클래스)보다 일반적인 개념/대상임을 의미하는 관계

삼각형 안에가 비어있는 모양임

• Is a 관계에 있으면 하위 클래스는 상위 클래스를 상속해서 받고 있고 상위 클래스의 모든 특성을 보유하며 자신만의 특성이나 메소드를 추가할 수 있다

Ex) polygon에 맴버변수 : line color, fil, point다 가짐 메소드 : 4 + 1.  2 개를 가짐(오버라이딩)

• 하위 클래스는 상위클래스로부터 물려받은 연산을 재정의할 수 있다(오버라이딩)

3-1) 추상클래스

• 객체를 생성할 수 없는 클래스

• 추상 클래스는 부모 클래스에 적을 수 있고 오버라이딩해주면 된다
• 추상 메소드가 없더라도 이텔릭체라면 추상클래스로 선언해 주어야 한다.

일반화 관계는 다형성을 가능하게 한다.

배열에 업케스팅해서 하나의 타입으로 배열로 넣어줄 수 있다.

호출 시 배열에 있는 것을 하나씩 꺼내어 메세지를 보내면 각자 자신의 방법으로 반응할 것 : 다형성, polymorphism

대체가능성(substitutability)

클래스 a가 기대되는 위치에 a의 자식까지 대신 사용될 수 있다!

대체가능성, 다형성 -> 다른 방법론보다 유지보수가 낮아졌다!

인터페이스

• 제공될 기능에 대한 명세 기능(specification), 약속은 클래스 컴포넌트에 의해 구현됨
• 인터페이스에 기술된 기능은 다른 모델 요소 즉, 클래스나 컴포넌트에 의해 구현된다
• 객체지향에서 인터페이스가 엄청엄청 중요한데 인터페이스는 추상메소드만 갖고 있으니까 이탤릭체로 표시하지만 추상클래스와 구별하기 떄문에 streo type으로 명시해준다

cf.

실선은 is a 관계임, 인터페이스는 문법적으로는 부모자식관계지만 실체화관계라고 해서 삼각형은 비어있고 점선으로 되어있음

추상클래스와 상속은 실선이지만 인터페이스는 점선

• 삼각형으로 해도 되고 인터페이스는 동그라미로 표시하기도 한다
  • 동그라미로 표시할 경우에는 실체화를 실선으로 표시하고 삼각형은 점선으로 표시한다.

• 인터테이스를 쓰면 명세와 구현을 분리할 수 있고 외부에서는 인터페이스만 보인다

추상클래스 vs 인터페이스

• 추상과 인터페이스의 차이는 추상클래스는 is a 관계이고 구현 일부 포함가능하지만 인터페이스는 be able to 관계를 만족할 때 사용

일반화와 실체화 관계

일반화 : is a kind of, is a

실체화 : be able to

학생은 clonale과 is a관계를 아니지만 able하고 싶어서 clone을 가짐

3) 의존관계

• 제공자의 변경이 이용자의 영향을 미칠 수 있음을 뜻한다
• 제공자의 변경의 이용자의 변경을 유발함을 의미
• 점선으로 표현

• 연관관계와 비슷하게 의존관계가 있는 클래스 간에 메세지를 전달 가능하지만 차이점은 범위, Lifecycle이 다르다
  • 이용자는 제공자 클래스의 연산을 호출할 수 있다.
• 의존관계
• 이용자 클래스의 연산의 인자 타입으로 제공자가 사용될 떄
• 이용자 클래스의 연산에서 제공자 클래스의 객체를 생성할 때
• 이용자 클래스의 연산에서 제공자 클래스의 전역 객체를 접근할 때

연관관계와 의존관계 비교

• 두 관게 모두 관련된 객체에게 메세지를 전달한다는 측면은 동일
  • 단, 연관관계는 맴버변수로 가진다면 의존은 연산 범위 내에서 존재

• 연관관계는 호출이 끝나도 라이프 사이클이 살아있지만 의존관계는 메소드 안에서만 살아있다.

• 연관관계는 서로 호출이 가능하지만 의존관계는 방향성이 이미 존재

의존관계는 인터페이스와 인터페이스 이용자 간에서 사용된다

캔버스는 인터페이스를 사용한다, 의존한다

클래스와 클래스면 실선이지만 canvas 클래스와 인터페이스는 의존관계이고 실현관계 또한 의존관계이기에 점선으로 표시

캔버스는 face를 모르고 idrawable만 안다

• 의존관계는 패키지 사이에서 유용하게 사용될 수 읻ㅆ다
• 패키지 간의 의존관계를 간단하게 의존으로 표시 가능하다