소프트웨어 공학 4(요구분석)

요구 모델링

• 고객과 개발자가 무엇이 개발되고 있는지에 동의하는 것을 주된 목적 으로 하는 요구 명세를 생성
  • 솔루션적인 부분은 포함 x

모델링 기초

전체를 다루기에는 너무 복잡한 대상을 추상화 또는 단순화

모델 사이의 관계

• 도메인 지식
  • 도메인 분석
• 요구 모델링
  • System Sequence diagram
    • 사용자와 시스템(외부)의 interaction 위주의 다이어그램
    • 시스템 내부의 동작에 대한 묘사는 없음
• 설계 모델링
  • 시퀸스 다이어그램
    • 유스케이스에 따른 시스템 내부에서의 동작도 포함하여 묘사

모델링 장점

• 개발팀원들 사이에 응용문제의 공통 개념으로 대화하는데 용이

객체 지향 언어 특징

객체 지향의 장점

• 설계자가 설계하기 쉽고, 개발자가 개발 용이
• 자료와 함수를 함께 추상화 함으로써 오류 발생 낮춤 -> 고신뢰도 SW

클래스와 객체

• 클래스
  • 속성과 오퍼레이션을 캡슐화(데이터가 보호됨, 객체를 생성하는 틀)
  • 데이터가 보호됨
  • 데이터를 원할 시 메서드 호출이 필요
• 객체
  • 클래스의 인스턴스
    • 내부 데이터(상태)가 계속 변화
  • 속성과 오퍼레이션을 가진 애플리케이션의 독립된 존재
• 속성
  • 객체의 현재상태를 담고 있음
    • 상태(state) : 객체 내부의 데이터 값(변수 값)

캡슐화(Encapsulation)

• 속성과 관련된 오퍼레이션을 클래스 안에 묶어서 하나로 취급하는 것
  • 데이터 : 학번, 이름, 주소 캡슐화
  • 메서드 : 평점 계산, 주소 변경, 수강 신청 ...
• 정보 은닉
  • 외부에서 데이터에 대한 직접적인 접근이 불가
• 구현에 따라 접근 권한 선택 가능
  • public, private, protected
    • protected : 상속에서 자식이 부모 데이터에 접근, 조회하도록 하는 데이터
    • 메서드는 대부분 public
    • data는 대부분 private

연관(association)

• 객체는 일반적으로 상호작용하여 동작
• 연관 : 하나 또는 그 이상의 클래스와의 관계
• 연관된 객체를 전역으로 선언하여 클라이언트 객체가 접근할 수 있게 함
• 연관된 객체를 클라이언트 객체의 메시지 호출 오퍼레이션의 매개변수로 만듬
  • 연관된 객체를 클라이언트 객체의 일부로 만듬 (합성관계)
  • 연관된 객체를 클라이언트 객체에서 선언 (집합관계)
  • Track과 Dist : 약한 포함(집합 관계)
    • *tracks와 같이 Dist 외부에 따로 tracks가 존재(다른 메모리에 존재)
  • Track과 Sector : 강한 포함(합성 관계)
    • Sector가 Track 내부에서 배열로 선언(Track 내부에 Sector가 존재)

class Disk {
    private:
        Track *tracks;
        disk information
    ...
};
class Track {
    private:
        Sector sectors[MAX];
    ...
};
class Sector {
    private:
    ...
};

상속(inheritace)

• 한 클래스가 다른 클래스의 일반화된 개념인 경우 성립(코드 중복을 줄일 수 있음)
  • 상속의 화살표는 빈 삼각형
  • 메서드는 데이터를 정하고 만듦
    • 상속에 의해 구분되는 데이터가 얼마 없다면 상속은 비효율적
• Super class, Sub class
  • 직원 - 관리자
  • Manager is_A Employee

다형성(polymorphism)

• 연산 내용은 달라도 동일한 개념이면 동일한 명칭의 메소드를 정의
• 현재 코드를 변경하지 않고 새로운 클래스를 쉽게 추가할 수 있음

UML(Unified Modeling Language)

• 객체지향 소프트웨어를 모델링 하는 표준 그래픽 언어
  • 시스템의 여러 측면을 그림으로 모델링
  • 하드웨어의 회로도 같은 의미
• 중요 다이어그램
  • 정적 모델링 : 클래스 다이어그램
  • 동적 모델링 : Use 다이어그램, Activity 다이어그램, State 다이어그램, Sequence 다이어그램
• UML 모델링 과정

1. 요구를 usecase로 정리하고 usecase diagram을 작성
2. 클래스 후보를 찾아내고 개념적 수준의 클래스를 작성
3. usecase를 기초하여 sequence diagram을 작성
4. 클래스의 속성, 오퍼레이션 및 클래스 사이의 관계를 찾아 객체 모형을 완성
5. state diagram과 activity diagram 등 다른 다이어그램을 추가하여 UML 모델을 완성
6. 서브시스템을 파악하고 전체 시스템 구조를 설계
7. 적당한 객체를 찾아내거나 커스텀화 또는 객체를 새로 설계
   
   
   

정적 모델링

• 시간의 개념이 개입되지 않은 모델 <=> 동적 모델링(시간 고려)
  • 실행타임을 고려함

클래스 다이어그램(정적 모델링)

• 클래스 및 객체들의 공통 구조와 동작들을 추상화 시킨 것

• 세 개의 부분으로 나누고 맨 위는 클래스의 이름, 중간에는 클래스의 속성, 아래 부분은 오퍼레이션을 적음
• 추상클래스는 {abstract}, 인터페이스 클래스는 <>추가
  • 추상 클래스
    • 추상 method가 포함되어 있는 Class
      • 추상 메서드
        • 이름만 있는 메서드
        • 상속받은 class들이 자신의 Class에 맞게 구현
        • 추상 메서드 외에 일반 메서드(구현이 된 메서드)도 존재
      • interface
        • 추상 메서드만 있음
        • 메서드의 표준화를 위해(통일성)

• 메서드, 변수 접근 구분
  • +:public
  • #:protected
  • -:private

클래스들 간 관계

상속(is - a)

• 한 클래스가 다른 클래스의 일반화된 개념인 경우 성립(코드 중복을 줄일 수 있음)
  • 상속의 화살표는 빈 삼각형
  • 메서드는 데이터를 정하고 만듦
    • 상속에 의해 구분되는 데이터가 얼마 없다면 상속은 비효율적
• Super class, Sub class
  • 직원 - 관리자(관리자의 경우 구현)
  • Manager is_A Employee
  
  
  

구현

• 인터페이스 활용한 구현
  • 질문? 상속에서 구현한다는 것은 인터페이스를 구현하는것만 취급?
  • 인터페이스 - 클래스 관계도 구현으로 취급?
  • 추상클래스 - 클래스 관계는 구현이 아닌 일반화?
• 실체화

연관

Class들 간 데이터를 주고받음, 연관이 복잡한 경우 연관 클래스가 새롭게 생김

• 연관관계 : 1대다, 다대다...
  • 0..* 는 최소 0부터 최대 多를 뜻함
• 이름 - 두 클래스 사이의 연관 관계를 나타냄
• 역할 - 연관 관계의 양쪽 끝에 있는 클래스의 기능을 나타냄
• 다중도(multiplicity)
  • 연관 관계를 구성하는 인스턴스의 개수
  • 연관관계에서 0, *와 같은것
    
    
    

집합

• 어떤 클래스가 다른 클래스의 모임으로 구성
  • ◆ == 합성(composition) : 강한관계(Vehicle이 삭제되면 Chassis와 Door도 같이 사라짐)
  • ◇ == 집합(Aggregation) : 약한관계(Vehicle이 삭제되어도 Chassis와 Dorr는 남아있음)
    
    
    

클래스 다이어그램 작성 과정

1. 클래스 후보 파악
2. 가장 중요한 클래스를 시작으로 Data(연관, 상속, 속성) 추가(Data 먼저 정의)
3. 클래스의 메서드 추가

클래스 유형

• 엔티티 클래스
  • 영구적으로 저장/검색/활용할 정보를 넣을 수 있음
  • 클래스 중 제일 먼저 작성
• 경계 클래스
  • 사용자가 자료를 시스템에 입력하기 위하여 필요한 양식 및 사용자 인터페이스에 해당
  • User Interface
• 제어 클래스
  • 비즈니스 로직 수행
  • Usecase에서 액터 하나 당 하나의 제어 클래스를 찾음

시험 유형

어떤 상황일때 다중도가 몇인지 묻는 문제 나옴

• 다대다인 이유
  • AirlineCompany 한 회사 내에서도 여러 Flight를 수행
  • 비행은 여러 AirlineCompany에서 이뤄짐

• 고객은 원하는 항공편을 찾아 동행 탑승자와 함께 예약, 좌석을 지정할 수 있음
• 항공편은 일정, 즉 출발 공항과 도착 공항이 있음, 출발, 도착시간 표시 필요
• 공항은 주변 여러 도시를 커버함(Airport - city가 다대다)
• 어떤 Flight는 중간기착지(stopover)이 있을 수 있음
  
  
  

• Professor과 Student는 Person에게서 상속
• 교수와 학생은 지도관계(1대다)
• 학생은 여러 분반을 참석, 여러 분반은 여러 학생을 가짐(다대다)
• 학생이 분반을 듣게 됨으로 성적이라는 연관 클래스 생성
• 성적은 성적표(Transcript)의 부분
  • 여러 등록과목이 합쳐져 성적표를 만듦
  • 이때 학생 한명은 한개의 성적표를 가짐(1대1)
• 교수는 여러 분반을 가르침(1대다)
• 하나의 Course(교과목)은 여러 분반을 가짐(1대다)
• 한 교과목은 여러 선수 교과목을 가질 수 있음, 반대도 가능(다대다)
  • self 관계
• 한 학기에 분반이 포함됨
  
  
  

동적 모델링

객체의 동작 흐름

클래스들의 상호작용이나 클래스의 상태 변화 등 시스템 내부의 동작을 모델링

• 시퀀스 다이어그램
  • 각 사용사례를 구현하기 위해 시간의 흐름에 따른 객체들간의 상호 작용을 표현
  • Usecase 1개당 1개의 Sequence Diagram
• 상태 다이어그램
  • 복잡한 객체의 상태 변화를 표현
  • 변수값의 변화
• 액티비티 다이어그램 : 시스템 전체 또는 복잡한 오퍼레이션의 작업의 흐름을 표현

시퀸스 다이어그램

시스템의 동작을 정형화하고 객체들의 메시지 교환을 울타리 형태로 시각화하여 나타낸 것

• 객체
  • Class의 인스턴스
  • 객체변수 : Class명
    • 객체변수는 생략해 :Class명으로 표기가능
• 라이프라인 : 객체는 존재하지만 실행x
• 활성막대 : 객체 실행
• 메시지 호출 : 함수 호출
• 프레임(Combined fragment)
  • 반복(loop)
  • 분기
    • alt : alternative(else가 있는 분기)
    • opt : option(else가 없는 분기)
  • 병렬(par)

상태(state) 다이어그램

객체가 가질 수 있는 가능한 상태 표현

• 이벤트 : 서브시스템 또는 객체나 컴포넌트에 대하여 요청이나 관심이 일어난 것
• 상태 : 이벤트의 발생으로 들어가거나 빠져 나오게 되는 서브시스템 또는 객체의 조건을 추상적으로 이름 붙여 놓은 것

• 레이블
  • e : event
  • [exp] : 조건분기문
  • / a1; a2 : 참이면 실행

)

• 각각의 state
  • 진입(entry) : 해당 상태로 들어올 때
  • 중간(do) : 해당 상태일때 실행
  • 탈출(exit) : 해당 상태를 탈출할 때
• 화살표 위 검정색 = event(메서드가 이벤트)
  • 일관성 체크를 위해선 해당 event가 클래스 다이어그램에 메서드로 존재하는지 확인
• Book Available : 상태
• [] 👉guard 가 포함된 상태 다이어그램도 존재

액티비티(Activity) 다이어그램

제어 모델링

Flow chart와 유사, 병렬성을 가짐

• 액티비티 사이의 제어흐름을 보여주는 일종의 흐름도
  • 액티비티 : 계산 또는 프로세스(메서드의 집합)
  • 전환 : 한 액티비티에서 다른 액티비티로 넘어감
  • 분기 : 진위 조건
• 사용시기 : 복잡한 부분을 보기 쉽게 표시하기 위해 사용
  • 시스템 수준에서 액터의 관점으로 모델링
  • 복잡한 메서드의 수행 흐름 표현

System level

• fork(검정색 바)
  • fork 위의 activity가 종료시 fork 아래의 activity가 동시다발적으로 실행
  • 여기서는 Request service와 Verify Customer가 종료시 Pay와 Scan tape가 실행
• 회색 박스에서는 state도 표현중

Method level