UML(Unified Modeling Language)
1. UML(Unified Modeling Language)
- UML은 소프트웨어를 시각적으로 모델링 하기 위해 사용
- UML은 소프트웨어를 모델링 하는 표준 그래픽 언어로 심벌과 그림을 사용하여 나타낼 수 있음
- UML의 목적은 소프트웨어 개발에 도움을 주는 것
- 개발 과정에 여러 가지 다이어그램으로 설계하면 구조가 좋아지고 개발자들 간의 의사 교환이 쉬어짐
- 액터와 사용 사례를 통해 시스템의 기능을 모델링 하는 데 사용
- 개발하려는 시스템의 기능적 요구 또는 업무 프로세스의 개관을 나타냄
- 요구분석 단계에서 많이 사용
use case diagram에서 많이 사용되는 심볼
- 객체 사이의 메시지 교환을 시간의 흐름에 따라 나타낸 것
- 즉, 사용 사례로 표시된 업무 프로세스에 대해 시스템 안의 존재하는 객체가 어떤 식으로 개입하여 상호작용하는지를 나타냄
- 객체지향 시스템의 가장 근간이 되는 다이어그램으로 시스템의 정적인 구조를 나타냄
- 또한 도메인(문제 영역)의 개념과 그것들 사이의 관계를 표시
3.4. 패키지 다이어그램
- 관련된 클래스를 패키지로 그루핑하여 복잡한 시스템을 조직화하는 데 사용
3.5. 상태 다이어그램
- 외부 자극에 대한 시스템의 동적 상태 변화를 나타냄
- 외부 이벤트에 대해 민감하게 상태를 변화시키는 객체를 모델링
- 시스템의 내부 프로세스를 단계별 작업 흐름 형태로 모델링
- 시스템의 동적 특징을 나타냄
- 노드, 컴포넌트, 커넥터 등 시스템의 물리적 자원 배치를 나타냄
디자인 패턴
- 자주 반복되는 설계 유형을 디자인 패턴이라 한다.
- 디자인 패턴은 체계적으로 문서화하여 범용적으로 사용할 수 있도록 정리한 것이다.
2.1. 개념 실체 패턴(Abstraction Occurrence Pattern)
- 각 객체의 공통 정보를 공유할 때 사용한다.
- 실체는 공통된 정보를 가진 멤버들의 모임이고, 개념은 공유하는 정보를 담는 클래스이다.
2.2. 플레이어 역할 패턴 (Player Role Pattern)
- 하나의 클래스에 다양한 역할을 표현하고 싶을 때 사용한다.
2.3. 위임 패턴(Delegation Pattern)
- 다른 클래스가 가진 특정 오퍼레이션을 활용하여 책임을 위임하고 싶을 때 사용한다.
- 계층 관계를 가진 객체들을 묶어 동일한 처리를 하고 싶을 때 사용한다.
5.1. 옵서버 패턴(Observer Pattern)
- 옵서버 패턴은 특정 데이터나 객체를 모니터링하고 있다가 변화가 발생하면 시스템이 이를 알리고 연관된 객체들이 변화에 대응하는 작업을 실행하도록 만들어준다.
5.2. 중재자 패턴(Mediator Pattern)
- 시스템을 이루는 객체들 사이의 밀접한 연관 관계를 효육적으로 처리해주는 패턴이다.
- 객체 내부의 변화나 특정 작업의 실행이 다른 객체에 영향을 미칠 때 중재자 객체가 중간에서 서로 간의 변화나 메시지를 조정하여 시스템이 원활하게 작동하도록 해준다.
5.3. 책임 체인 패턴(Chain of Responsibility Pattern)
- 사용자가 원하는 작업을 어떤 객체에게 시킬지 모를 때 그 작업을 다룰 만한 객체들의 집합에 던져버리는 패턴이다.
5.4. 커맨드 패턴(Command Pattern)
- 작업을 처리할 객체 집단에서 처리를 담당할 객체를 직접 지정한 후 그 객체를 처리 박스에 요청하여 처리하는 패턴이다.
5.5. 상태 패턴(State Pattern)
- 상태를 객체로 만들고 상태에 관련된 모든 행위를 하나의 객체로 모으는 패턴이다
구현
- 설계 명세를 토대로 분리하여 구현할 수 있는 작은 단위별로 프로그래밍하는 것을 말한다.
- 사용자의 요구를 만족시키는 프로그램을 만들려면 상세 설계나 사용자 지침서에 기술된 것과 일치하도록 코딩을 해야 한다.
- 코딩 표준은 코드를 읽기 쉽고 이해하기 쉽게 작성하기 위한 규칙과 가이드라인을 제공한다.
- 코딩 스타일을 표준화하면 개발 및 유지 보수 비용과 시간이 줄어들어 소프트웨어의 생산성과 품질을 높일 수 있다.
- 대부분의 개발 팀은 프로그래머가 정해진 코딩 표준을 따르도록 교육하고 있다.
- 참고 URL
- 리팩토링이란 기능의 변경 없이 코드의 디자인을 개선하는 것으로, 문제가 될 만한 부분을 찾아내어 수정하고 재구조화하는 작업이다.
- 리팩토링을 하면 코드를 쉽게 이해할 수 있을 뿐만 아니라 확장 및 재사용할 수 있다.
- 더 읽기 쉽게 하고, 결합을 낮추며, 응집을 높여서 코드를 쉽게 변경할 수 있도록 하는 것이다.
- 작은 변경을 가한다.
- 모두 잘 작동된다는 것을 확인하기 위해 테스트한다.
- 모두 잘 작동된다면 다음 리팩토링으로 넘어간다.
- 작동되지 않으면 문제를 수정하거나 원상 복구하여 시스템이 작동되도록 유지한다.
- 설계를 수정하기 어렵게 만드는 코드를 코드 스멜이라 한다.
- 중복 코드
- 긴 메소드
- 큰 클래스
- 많은 케이스를 가진 case 문장
- 긴 메소드 호출
- 지나친 널 객체 체크
- 유사 데이터의 중복
- 데이터 클래스(메소드는 거의 없고 속성만 많은 클래스)
- 캡슐화되지 않은 필드
- 이러한 코드 스멜을 줄이기 위한 방법은 아래와 같다.
- 클래스 추출
- 메소드 추출
- 서브 클래스 추출
- 템플릿 메소드 형성
- 메소드 이동
