Object-oriented paradigm and software design <2-1>
<< 2주차 Lecture Note 1번째 >>
- Good Software Design
- Object-oriented Design
- UML(Unified Modeling Language)
Good Software Design
소프트웨어 설계를 잘 한다는 것은 5가지 요건을 갖도록 설계하는 것이다.
1. Correctness
- 소프트웨어 설계 자체가 사용자의 목적에 적합해야 한다.
- 설계된 소프트웨어는 오류 없이 작동해야 한다.
2. Robustness
- 설계된 소프트웨어가 모든 상황에서 적합해야 하는 것은 아니지만,
예상 범위 내에 있는 overload에 대해 상당 수준 커버가 가능해야 한다.
3. Flexibility
- 소프트웨어 설계는, 특정 상황에만 들어맞는 설계보다 일반적으로 유연하게 적용할 수 있도록 확장성을 가져야 한다.
4. Usability and Reusability
- 기존 설계 목적 외에 다른 부분에서도 재활용 가능하도록 설계하는 것은 워크프로세스에서 효율성을 높여준다.
5. Efficiency
- 사이즈가 작은 설계로 빠르게 실행할 수 있어야 한다.
- 설계의 구현이 쉬워야 한다.
Object-oriented Design
객체지향 설계는 현실의 개념을 추상화 시켜 프로그램의 모듈로 만들고 설계에 녹이는 것이다.
현실의 개념을 추상화 시킨다는 것이 뭘까?
가령 고객이 은행 입출금 거래를 한다고 생각해보자.
현실에는 고객이 존재하고, 입출금이라는 실제 행동을 한다. 그럼 은행의 계좌에 변동이 발생한다.
즉, 현실에는 고객(Customer), 입출금(Transaction), 은행시스템(Banking) 이 존재한다.
이것을 추상화시켜 보면 아래 그림과 같다.
customer를 예로 들면, 현실의 개념을 추상화하는 것은 아래와 같다.
- 현실의 불특정 고객을 클래스로 생성
- ID와 AccountNum은 현실 고객의 이름과 계좌번호 등의 고객 특성을 내부 변수로 생성
- 고객이 현실에서 하는 행동(은행시스템 로그인, 인출요청, 보안확인)은 메서드로 생성
이렇게 추상화한 모듈을 사용함으로써,
A 고객, B 고객, \(\cdots\), Z 고객까지 모두 하나의 Customer 클래스의 객체(Instance)로 관리할 수 있게 된다.
UML(Unified Modeling Language)
소프트웨어 설계는 설계자뿐만 아니라 구현과 유지보수 개발자, 이해관계자 등이 모두 이해할 수 있어야 한다.
따라서 현업에서는 UML이라고 하는 설계 표준을 사용해 소프트웨어를 설계한다.
UML은 어떤 언어의 문법처럼 소프트웨어 설계를 위해 표준으로 정의한 표시 또는 언어를 말한다.
여기서는 Class와 Instance 기반의 UML을 알아보자.
UML notation은 아래와 같다.
1. Class → 소프트웨어 설계시 클래스 이름을 지정한다.
- 특정 인스턴스를 설계에 표현해야 할 경우 콜론 2개를 이용해 \(\mathsf{name::Class}\) 형태로 표현한다.
- 이름이 정해지지 않은 인스턴스는 콜론 1개를 이용해 \(\mathsf{:Class}\) 형태로 표현한다.
2. 각 클래스의 구성 요소에는 Visibility option이 붙는다.
- + → public: 모든 것에서 확인 가능
- # → protected: 해당 클래스와 관련된 것에서만 제한적으로 확인 가능
- - → private: 해당 클래스 내부에서만 확인 가능
3. 각 클래스의 멤버 변수, 메서드에는 type을 지정한다.
- 멤버 변수의 type은 그 자체로 변수의 type이 되며, 메서드의 type은 return하는 값의 type이 된다.
- 멤버 변수 → +-#(variable name):(type) = (default value) (default value는 지정하지 않을 수도 있다.)
- 메서드 → +-#(method name)(args):(type)
notation으로 표현한 <그림 1>의 Customer 클래스는 이렇게 구성된다.
