오늘 배우게 된 주제
- 응집도, 결합도
- UML
- 계산기 프로젝트을 위한 (중위 연산자 → 후위 연산자) 알고리즘
응집도, 결합도
- 응집도 : 정보 은닉 개념을 확장한 것으로, 명령어나 호출문 등 모듈의 내부 요소들의 서로 관련되어 있는 정도, 즉 모듈이 독립적인 기능으로 정의되어 있는 정도를 의미한다
- 결합도 : 모듈 간에 상호 의존하는 정도 또는 두 모듈 사이의 연관 관계를 의미한다. 결합도가 강하면 시스템 구현 및 유지보수 작업이 어렵다
UML(Unified Modeling Language)
참고)
Swift UML 관계 정리
통합 모델링 언어는 객체 지향 프로그래밍 소프트웨어 집약 시스템을 개발할 때 산출물을 명세화, 시각화, 문서화할 때 사용한다
보통의 줄글로 시스템 전반에 대해서 설명하는 것 보다 도식화 / 시각화를 통해 설명하는 것은 굉장히 중요하다!
UML 작성을 통해서 의사소통을 좀 더 효율적으로 할 수 있다. 표준화된 표기법을 통해서 도식화 / 시각화를 누구나 알아볼 수 있게 한다!!
근데 왜 Language인가? standard나 type이 맞지 않을까?
Language : the principal method of human
communication, consisting of words used in astructuredandconventionalway and conveyed by speech, writing, or gesture
Language 자체가 communication 방법을 말하는 것이기에 괜찮다~
누구와 의사소통을 하는 것인가??
- 나 자신 → 전체 구조 및 클래스 의존성 파악
- 같이 일하는 사람 → 의사소통 및 설계 논의
- 미래에 이 프로그램을 유지보수할 사람 → 문서화
객체지향에서는 의존성을 줄이는 것이 굉장히 중요하다. 유연하고 확장성 있는 구조를 만들어주기 때문이다. 궁극적으로는 단일 책임 원칙, 확장에는 열려있고, 수정에는 닫힌 구조를 가져올 수 있다. SOLID 원칙과도 관련이 있다.
단일 책임 원칙 - 위키백과, 우리 모두의 백과사전
SOLID (객체 지향 설계) - 위키백과, 우리 모두의 백과사전
UML을 그려서 프로젝트의 전체를 파악하게 되면 어떤 부분에서 의존성이 강한지 파악하기 편하다!!
UML의 구성요소
- 사물
- 관계
- 다이어그램
사물 = 사물은 모델을 구성하는 가장 중요한 기본 요소로, 다이어그램 안에서 관계가 형성될 수 있는 대상들을 말한다. 구조, 행동, 그룹, 주해 사물
관계 = 관계는 사물과 사물 사이의 연관성을 표현하는 것으로, 연관관계, 집합관계, 포함관계, 일반화관계, 의존관계, 실체화관계가 있다
다이어그램 = 사물과 관계를 도형으로 표현한 것이다.
1) 정적 모델링(시스템의 개념, 관계등의 측면)에서는 주로 구조적 다이어램
2) 동적 모델링(시간의 흐름 중간 중에 한 순간)에서는 행위 다이어그램을 사용한다.
구조적 다이어그램과 행위 다이어그램은 또 여러 가지 다이어그램으로 쪼개진다.
구조적 다이어그램은 주로 Class Diagram을, 행위 다이어그램은 Sequence Diagram을 많이 사용한다고 한다
관계는 위와 같이 표현할 수 있다. 각, 다른 관계를 의미하는데,
일반화 관계 = 하나의 사물이 다른 사물에 비해 더 일반적인지 구체적인지를 표현한다. swift에서는 상속에 어울린다
실체화 관계 = 사물이 할 수 있거나 해야 하는 기능으로 서로를 구룹화할 수 있는 관계를 표현한다.
집약 관계 (집합) = 하나의 사물이 다른 사물에 포함되어 있는 관계를 표현한다.
합성 관계 (포함) = 집합 관계의 특수한 형태로, 포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계를 포함한다. 포함하는 쪽과 포함되는 쪽은 서로 독립적이지 못하고, 생명주기를 함께한다.
의존관계 = 서로 연관은 있으나 필요에 의해 서로에게 영향을 주는 짧은 시간 동안만 연관을 유지하는 관계를 표현 (stored Property, method's argument, method 안에서 잠깐 사용되는 local variation에서도 클래스가 사용되면 둘 사이에 의존 관계가 있다고 한다)
<3월 28일 내용 추가>
클래스 다이어그램 기본 요소 중 access Level 표시
| + | Public |
|---|---|
| # | Protected |
| - | Private |
| ~ | Package |
연관관계(Association) vs 의존관계(Dependency)
연관관계
다른 객체의 참조를 가지는 인스턴스 변수를 가지고 있을 때 두 클래스는 연관 관계라고 합니다. 아래 그림은 Phone 클래스가 Button 클래스를 참조하는 연관 관계를 보여줍니다.
(Phone -> Button)
class Phone {
// buttons 프로퍼티의 타입이 Button 클래스
let button: Button
}
class Button {
}- 중요) 생성된 인스턴스에 대한 참조를 유지한다는 것이 특징
의존관계
한 클래스가 다른 클래스를 참조하는 관계입니다. 한 클래스의 내부 프로퍼티에 저장하지 않고 사용하는 관계를 의존 관계라고 합니다. 아래 그림은 User 클래스가 Scheduel 클래스를 의존하는 관계를 보여줍니다.
class Schedule {
func date() {
}
}
class User {
func createSchedule() -> Schedule {
Schedule()
}
func useSchedule(schedule: Schedule) {
schedule.date()
}
}-
중요) 즉 의존 클래스의 인스턴스 변수를 유지하지 않는다
-
한 클래스의 메소드가 다른 클래스를 인자로 받아 메소드내에서 사용
-
한 클래스의 메소드 내에서 다른 클래스를 생성하고 생성된 클래스의 메소드를 사용한다 (메소드 내에서만 사용하고 메소드 반환시 의존 클래스 인스턴스도 함께 사라진다
-> 즉 로컬 변수로만 사용)
-
흰이 추천해준 툴
명심할 것!!!!
-
UML diagram 이 너무 복잡하다?
→ 쪼개기, 상위 개념에서 생각해보기!!
-
처음부터 완벽하게 그릴 수는 없음!
→ 많은 수정은 좋은 구조로 가는 길...
-
꼭 지켜야 하는 법칙 X / 버전이 너무 많다... 이걸 다 알아야해?
→ 의사소통이 목적임을... 이 자체가 코딩을 위한 수단이 아님을 잊지말자!!!
계산기 프로젝트을 위한 (중위 연산자 → 후위 연산자) 알고리즘
느낀점
오늘 흰이 준비해준 코드를 UML로 표현해 보았는데, 처음 UML을 작성하는 것이라 관계를 그리는 것이 익숙하지 않았다. But, 그림으로 그리고 나니깐 class 간의 관계가 한번에 이해가 되고, 클래스간의 의존관계를 파악하기 굉장히 용이하였다.
주말에 시간이 된다면, 이전에 진행하였던 프로젝트 3개를 모두 UML을 통해서 관계파악을 하며, 좋지 않은 의존관계가 있다면 끊어볼 생각이다.
