소프트웨어 공학 (Software Engineering ) 객체지향 설계 문양세 강원대학교 IT 대학 컴퓨터과학전공

1. 소프트웨어 공학 (Software Engineering) 객체지향 설계 문양세 강원대학교 IT대학 컴퓨터과학전공

2. 학습 목표 객체지향 분석과 설계 객체지향 개념 UML 2.0 다이어그램 정적 모델링, 동적 모델링, 디자인 패턴 (간략히 설명)

3. 객체지향 기술 • 절차적인 방법은 조그만 변화에도 영향이 큼 최근에는 객체지향 설계, 언어가 매우 일반화된 추세임 • 함수와자료를 함께 클래스로 묶음으로 여러 장점을 얻을 수 있음(예제: 스크롤러– 여러 환경에 적용되며, 독립적인 수정/관리가 가능) • 장점 • 추상화, 모듈화, 정보은닉등 설계 원리에 충실 • 복잡함을 잘 다룰 수 있음 • 특징 • 유사성을 이용하는 방법을 제공 (클래스 도출) • 뚜렷하게 구별되는 단위로 분할 • 코드 재사용에 의하여 생산성을 높임 • 빠른 속도로 적용, 산업계 표준화

4. 6.1 객체지향 분석과 설계 문제 자체의 이해 구현 기술도 고려 • 객체지향 분석 및 설계의 특징 • 분석과 설계의 과정이 순차적(절차적)이 아님 • 분석과 설계 과정을 명확히 구분하기는 어려움 • 한번의 싸이클로 작업이 끝나지 않고, 반복적인 싸이클로 완성 • 분석은 문제 영역, 설계는 솔루션 영역을 다룸

5. 객체지향 분석 설계 과정 “객체” (클래스) 뚜렷한 표준 프로세스는 없음 (경험적 요소에 상당히 의존적임) 사용사례는 맨 처음, 최종 목표는 클래스 다이어그램

6. 객체지향 모델 • 여러 다양한 관점에서 시스템을 모델링 • 객체지향에서는 크게 세 가지 관점의 모델을 작성 • 기능적 모델: 사용자에게 보이는 외부 기능을 중심으로 모델 작성 • 정적 모델: 시스템을 구성하는 요소인 객체들의 관계를 모델링 • 동적 모델: 객체의 상태 변화 등 시간적 요소가 고려된 모델

7. 학습 목표 객체지향 분석과 설계 객체지향 개념 UML 2.0 다이어그램 정적 모델링, 동적 모델링, 디자인 패턴 (간략히 설명)

8. 6.2 객체지향 개념 • 객체지향에서는 주어진 문제 영역을 그 안에 존재하는 “객체의 집합”으로 보며, 객체들은 서로 정보를 주고받아 “상호작용”한다 여긴다. • 객체지향 개념에서는 소프트웨어를 여러 개의 객체의 모임으로 생각하며, 객체는 데이터와 관련 함수를 모아 놓은 것이다.

9. 객 체 • 객체의 정의 • 소프트웨어 모듈(객체) = 자료구조 + 함수 • 객체는 상태(state), 능력(behavior), 정체성(identity)을 가진다. • 상태: 자료구조가 객체 (인스턴스) 고유의 값을 가짐 • 능력: 연산(operation)을 수행 할 수 있는 능력 • 정체성: 구별 가능성 (사과들도 각기 모양이 구분됨, 쌍둥이도 구별됨) • 객체 인스턴스(instance) = 객체 • 비슷한 객체의 구조와 행동은 공통 클래스로 선언

10. 클래스(Class) [1/2] • 클래스(class) vs인스턴스(instance) • 클래스 : 객체의 타입(object type) • 인스턴스:클래스에 속하는 개개의 객체 • 클래스의 속성(attribute) • 예 : 직원 클래스 • 속성 : 이름, 직위, 월급, 전화 번호 등 • 함수 : 진급, 월급 인상, 전화 변경 등 직원클래스 홍길동 객체

11. 클래스(Class) [2/2] • 클래스는 유사한 개념의 객체(클래스)들을 그룹핑하는 효과 • 클래스는 객체들이 갖는 속성과 적용 연산을 정의하고 있는 틀(template) • Employee Hong_kildong(); • Employee* Hone_kildong = new Emplyoee();

12. 캡슐화(Encapsulation) • 캡슐화의 정의 • 관련된 항목을 모아서 갭슐을 씌움 • 예> 학사 관리 시스템 • 데이터 : 학번, 이름, 주소의 캡슐화 • 함수: 평점 계산, 주소 변경, 수강 신청의 캡슐화 • 추상화의 수단 • 세부사항은 차후에 생각 • 정보은닉(information hiding) • 외부의 직접적 접근 불가, 일종의 블랙박스 • 구현에 따라 선택 가능 • 문법 : public, private, protected

13. 객체 사이의 관계 Publisher Book 1 * • 객체는 일반적으로 상호작용하여 동작 • 객체에 있는 서비스를 호출하면 두 객체는 관계가 맺어져야 함 • 상호작용할 필요가 있는지 찾아내는 작업이 필요 • 연관 (association) • 서로 상대의 존재를 알 수 있도록 관련이 맺어진 것 • 예) 책과 출판사 • 집합 관계 (set relationship) • 전체 개념과 부분 개념 사이의 관계 • 격납(containment)의 의미 • 예) 디스크  트랙  섹터

14. 상속(inheritance) [1/2] • 상속의 의미 • 상위 클래스의 속성과 연산을 물려 받음 • 슈퍼클래스(superclass), 서브 클래스(subclass) • 예) • 직원 : 슈퍼클래스 • 관리자 : 서브클래스

15. 인사대상 학 생 교원 직 원 학부생 대학원생 상속(inheritance) [2/2] • 복수상속 (multiple inheritance) • 두 개 이상의 수퍼클래스에서 상속 받음

16. 다형성(polymorphism) [1/2] • 다형성의 정의 • 여러 형태를 가지고 있다 (=여러 형태를 받아들일 수 있다) • 같은 이름의 메시지를 다른 객체 or 서브클래스에서 호출 • 예> getArea() 를 도형의 모양이 달라도 호출

17. 다형성(polymorphism) [2/2] • 메소드: 특정한 클래스를 위하여 오퍼레이션을 구현 • 하나 이상의 메소드를 가진 오퍼레이션 • 매개변수나 객체가 속한 클래스의 이름으로 구분 • 현재 코드를 변경하지 않고 새로운 클래스를 쉽게 추가할 수 있음 • In Java, C++ • method overloading? • method overriding?

18. 학습 목표 객체지향 분석과 설계 객체지향 개념 UML 2.0 다이어그램 정적 모델링, 동적 모델링, 디자인 패턴 (간략히 설명)

19. 6.3 UML이란? • 객체지향 소프트웨어를 모델링 하는 표준 그래픽 언어 • 시스템의 여러 측면을 그림으로 모델링 • 클래스 기술(정의)뿐 아니라, 클래스간 상호작용을 표현 • 하드웨어의 회로도 같은 의미

20. UML 역사 [1/2] • 1980년대 말부터 1990년대 초에 객체지향으로 모델링 하는 과정과 모델링 언어 출현 • 설계와 표현 방법의 급증으로 혼란을 초래 • Rumbaugh와 Booch가 1994년 두 가지 방법을 합병하기로 함 • Rational Software 라는 회사 설립 • 1995년 Jacobson이 팀에 합류 • 사용 사례를 제안 • 1997년 Object Management Group(OMG)이 UML 표준화 추진  UML V1.0 • 2003년 6월 UML V2.0 제정

21. UML 역사 [2/2]

22. UML 모델의세 가지 관점 • 기능적 관점: 사용자 측면에서 본 시스템의 기능 •  UML에서는 주로 분석 단계에서 사용하는 사용 사례 다이어그램으로 표현 • 구조적 관점(정적 모델) • 시간 개념을 포함하지 않음 • 시스템의 구조적 측면으로, 클래스 혹은 객체의 관계, 클래스 그룹의 의존 관계 등을 다이어 그램으로 나타냄 • UML: 클래스 다이어그램, 컴포지트 다이어그램, 컴포넌트 다이어그램 등 • 동적 관점(동적 모델) • 특정 시각의 시스템 동작을 스냅 사진으로 찍어놓은 형태 • 시스템의 상태, 기능을 실행하는 순간의 객체들의 협력 등을 나타냄 • UML: 인터랙션 다이어그램, 상태 다이어그램, 액티비티 다이어그램 등

23. UML 다이어그램

24. UML 다이어그램

25. UML 다이어그램

26. 학습 목표 객체지향 분석과 설계 객체지향 개념 UML 2.0 다이어그램 정적 모델링, 동적 모델링, 디자인 패턴 (간략히 설명)

27. 6.4 정적 모델링 • 정적 모델 • 시간의 개념이 개입되지 않은 모델 • 클래스 다이어그램이 대표적 • 클래스 다이어그램 • 객체, 클래스, 속성, 오퍼레이션, 연관 등을 표현

28. 6.5 동적 모델링 • 클래스들의 상호작용이나 클래스의 상태 변화 등 시스템 내부의 동작 • 동적 모델링의 세가지 다이어그램 • 인터랙션다이어그램 • 상태 다이어그램 • 액티비티 다이어그램

29. 6.6 디자인 패턴 • 프로그램 개발에 자주 등장하는 문제를 기술하고 같은 작업을 반복하여 설계하지 않고 여러 번 반복하여 사용할 수 있는 문제에 대한 솔루션을 기술한 것 • 패턴 • 여러 가지 상환에 적용될 수 있는 템플릿과 같은 것 • 문제에 대한 설계를 추상적으로 표현한 것 • 문제를 해결하려는 요소들을 일반화하여 잘 정리한 것 • 커스텀화된 객체나 클래스의 연결을 나타낸 것 • 패턴의 구성 요소 • 패턴의 이름과 구분 : 패턴을 부를 때 사용하는 이름과 패턴의 유형 • 문제 및 배경 : 패턴이 사용되는 분야 또는 배경, 해결하는 문제를 의미 • 솔루션 : 패턴을 이루는 요소들, 관계, 협동 과정 • 사례 : 간단한 적용 사례 • 결과 : 패턴을 사용하면 얻게되는 이점이나 영향 • 샘플 코드 : 패턴이 적용된 원시코드

30. 자세한 사항은 … • 6.4~6.6의 UML 관련 자세한 사항은 생략 • 관심있는 학생은 교재의 내용을 참조하시고, • 더 관심 있는 학생은 간단한 온라인 자료를 참조하시기 바랍니다. • 또한, StarUML등 UML 저작도구도 있으니 참조 바랍니다. • http://blog.naver.com/iceprce?Redirect=Log&logNo=150135958399

31. Questions?