[소프트웨어공학] 6장. 아키텍처 설계와 클래스 설계

01 아키텍처 설계

• 아키텍처의 필요성
  • 아키텍처 품질 속성(성능/가용성/사용성/편의성/운영성/확장성 등)을 고려하지 않고 원칙, 지침, 표준을 지키지 않으면 좋은 시스템이 될 수 없다.
  • SW 아키텍처에서는 기능적인 요소뿐만 아니라 여러 시스템의 비기능적인 요소에 집중한다.
  • software architecture 위치 : requirements - software architecture - implementations
  • 소프트웨어 아키텍처
    • 소프트웨어 구성 요소들 사이에 유기적 관계를 표현하고 소프트웨어의 설계와 업그레이드를 통제하는 지침과 원칙
• SW 아키텍처의 특징과 기능
  • SW 골격이 되는 기본 구조
  • SW 구조, 구성 요소(속성), 구성 요소 간의 관계
  • 시스템에 대한 큰 밑그림 
  • 구성 요소 간의 상호작용 정의
  • 세부 내용보다 핵심 내용에 집중
  • 설계에 적용되는 원칙과 지침 존재
  • 요구사항과 코딩의 가교 역할
• 올바른 architecture 설계
  • 모든 이해 관계자 사이의 의사소통 도구(개발 비용, 기간, 조직의 역량 등)로 활용할 수 있어야 한다.
    → 구현에 대한 제약사항을 정의해야 한다.
  • 모든 이해관계자의 품질 요구사항을 반영한다.
    → 우선순위에 따라 시스템 품질 속성(성능, 사용성, 보안성, 안정성, 검증 가능성, 변경 용이성 등)을 결정해야 한다.
  • 특정 문제 영역에 적합한 SW의 구성 요소를 재사용(표준화, 패턴화)할 수 있도록 설계해야 한다.
• 아키텍처 설계의 효과
  • 소프트웨어의 기본 골격이 만들어진다.
    • 개발 참여자의 이해의 폭이 넓어진다.
    • 구현 상의 문제점을 도출할 수 있다.
  • 분할 방법을 찾을 수 있다.
  • 구조화를 위한 구체적인 방안을 생각할 수 있다.
  • 설계의 원칙과 가이드를 제공할 수 있다.
  • 설계를 재사용할 수 있다.
  • (소프트웨어 아키텍처를 기준으로) 개발 조직을 만들 수 있다.
  • 전사 조직을 (소프트웨어 아키텍처에 맞게) 재편할 수 있다.
  • 품질 특성에 대한 평가 방법을 결정할 수 있다.
• 아키텍처 품질 속성
  • SEI의 SAiP 품질 모델의 품질 속성
    • 시스템 품질 속성
      • 가용성, 변경 용이성, 성능, 보안성, 사용성, 테스트 용이성
    • 비즈니스 품질 속성
      • 시장 적시성, 비용과 이익, 예상 시스템 수명, 목표 시장 신규 발패(공개)일정, 기존 시스템과의 통합
    • 아키텍처 품질 속성
      • 개념적 무결성, 정확성과 완전성, 개발 용이성
  • 품질 요구사항
    • 많은 품질 속성 중에서 사용자가 요구하는 품질 속성 → 아키텍처에서는 결정한 사용자의 품질 요구사항을 반영해야 한다.
  • 아키텍처 설계 시 품질 속성 반영 방법
    • 중요 품질 속성 결정: 해당 프로젝트에서 중요하게 생각하는 품질 속성을 결정한다.
    • 품질 속성 수준 결정: 결정한 품질 속성을 어느 정도 수준으로 설계할 것인지 목표를 설정한다.
    • 목표 달성 방법 기술: 설정한 목표를 달성할 수 있는 방법을 서술한다.
    • 품질 속성 평가 방법 기술: 품질 속성을 평가할 방법을 서술한다. 
  • 아키텍처 품질 속성의 예: 사용자가 보안을 중요시할 때의 아키텍처 설계
    • 많은 품질 속성 중 보안성을 선택한다.
    • 아키텍처 스타일 중 계층 구조 스타일을 선택한다.
    • 보호해야할 요소를 가장 깊숙한 내부 계층에 둔다. 
    • 높은 등급의 보안 인증을 통과해야만 사용할 수 있도록 설계한다.
  • 시스템 품질 속성
    • 가용성(availability): 시스템이 운용될 수 있는 확률로, 시스템이 장애 발생 없이 서비스를 제공할 수 있는 능력
    • 변경 용이성(modifiability): 사용자가 새로운 요구사항(기능 추가, 불필요한 기능 제거, 오류 수정, 보안 강화, 성능 개선 등)을 요청했을 때 얼마나 쉽게 변경할 수 있는지의 정도
      • 변경이 미치는 영향을 쉽게 찾아야하기 때문에 추적이 가능하도록 아키텍처를 설계
      • 자주 변경되는 SW 라면, 변경 용이성을 다른 품질 속성보다 우선적으로 고려하여 architecture를 설계
    • 성능(performance): 사용자 요청과 같은 evnet가 발생했을 때, 얼마나 빠르고 효율적으로 기능을 수행할 수 있는지의 능력
      
      • 성능이 중요한 SW 라면, 공유 자원을 어떻게 사용하는지, 어떤 algorithm을 사용하는지 등의 요소와 밀접 → 모듈의 규모를 크게 하여, subsystem 간의 통신 횟수가 적도록 설계한다.
      • 성능의 표현: '사용자 요청에 관한 결과를 제공하는 대기시간(latency)' 혹은 '초당 처리할 수 있는 트랜잭션의 수'로 표현
    • 보안성(security): 허용되지 않은 접근에 대응할 수 있는 능력
      • 시스템 접근의 적법성을 가릴 수 있도록 아키텍처 설계 →  승인되지 않은 사용은 차단하고, 올바른 사용자에게는 서비스를 제공함
      • 인증을 받은 일부만 접근할 수 있도록 계층 구조 아키텍처를 사용해 가장 안쪽 계층에 중요한 자료를 저장한다.
    • 사용성(usablility), 사용 편의성, 사용 용이성, 사용 가능성, 편의성: SW를 사용할 때 혼란스러워 하거나 사용하는 순간에 고민하지 않게 하는 편의성
      • 시스템을 사용할 때 발생할 수 있는 여러 가지 상황을 극복할 수 있도록 아키텍처 설계
      • 예) 도움말 기능, 친숙한 인터페이스, UNDO(취소) 기능
    • 테스트 용이성(testability): Test를 위한 architecture를 설계 시 고려 사항
      • 결함을 찾기 위해 test가 얼마나 효과적으로 수행되는지
      • test에 소요되는 시간을 얼마나 단축할 수 있는지
  • 비즈니스 품질 속성
    • 시장 적시성(time to market): 정해진 날짜에 SW를 출시해 경쟁력을 높일 수 있는 정도
    • 비용과 이익(cost and benefit)
      • 아키텍처 설계 
        • 유연한 설계: 비용 ↑ , 범용성 ↑ , 확장성 ↑ , 변경 용이성 ↑
        • 맞춤형 설계: 비용 ↓ , 범용성 ↓ , 확장성 ↓ , 변경 용이성 ↓
    • 예상 시스템 수명(predicted lifetime of the system)
      • 시스템 사용 시간
        • 수년 사용 시 : 고려 사항 없음
        • 장기간 사용 시 : 지속적인 수정 및 보완 필요, OS 또는 HW 교체 고려
          → 확장성 및 이식성 고려 필요 
    • 목표 시장(targeted market)
      • 명확한 목표 시장
        • 타사 제품보다 뛰어난 기능
        • 타사 제품보다 다양한 플랫폼에서 구동
        • 타사 제품보다 사용자의 요구를 즉각 반영
          → 기능성, 이식성, 변경 용이성, 추적 가능성 필요
    • 신규 발매(공개) 일정(roll-out schedule)
      • 확정된 출시 일정까지 완료가 어려운 경우
        • 현재 버전: 기본 기능만 제공
        • 차기 버전: 기능 추가 완성
          → 유연성, 확장성 필요
    • 기존 시스템과의 통합(intergration with legacy system)
      • 기존 시스템과의 통합
        • 기존 시스템 특성(DB, OS, 아키텍처 설계, protocol 등) 및 제약 사항 파악
          → 유연성, 확장성 필요
  • 아키텍처 품질 속성
    • 개념적 무결성(conceptual integrity), 일관성
      • 세부 구성 요소를 전체 시스템으로 통합하더라도 일관성이 유지되어야 한다.
      • 전체 시스템과 시스템 구성 요소가 일관되도록 아키텍처를 결정
    • 정확성과 완전성(correctness and completeness)
      • 사용자가 요구하는 기능을 충족시키는 정도
      • 요구 분석 명세서와 일치하는 정도
    • 개발 용이성(buildability), 구축 가능성
      • 전체 시스템을 적절한 모듈로 분할한 후 개발 팀에 알맞게 분배하여 개발함으로써 정해진 기간 내에 완성하고, 개발 과정 중에도 쉽게 변경할 수 있는 능력
• 아키텍처의 4+1 관점
  • 어떤 사물에 대해 제대로 파악하려면 다양한 관점으로 검토 필요
    → 관점 : 시스템을 이루는 요소들의 집합 and 그들의 관계를 추상적으로 표현한 것
    

    

    

• 시나리오 관점 (scenario(usecase) view)
  • 최종 사용자가 인식할 수 있는 시스템의 기능
  • 시스템이 사용자에게 제공하는 기능에 주목하는 관점
  • 기능 하나하나가 usecase로 표현되기 때문에 usecase view라고도 한다.
  • 4개 관점에서 사용되는 다이어그램의 근간
  • 분석 및 설계의 과정에서 사용
  • 설계자와 사용자의 의사소통에도 사용
• 논리적 관점 (logical(design) view)
  • 시스템 내부를 들여다 본다.
  • 시스템의 기능이 어떻게 제공되는지 설명 → class, component의 종류와 이들의 관계에 초점
• 프로세스 관점(process view)
  • 모든 클래스가 아닌, 독자적인 제어 thread를 가질 수 있는 클래스에 초점을 맞춤
  • 시스템과 동시성과 동기화에 관심
    → 시스템에 어떤 processs와 thread가 있는지 식별하고, 그들의 관계(소유, 동기화 등) 표현
    → UML에서의 표현: 동적클래스의 stereotype
• 개발 관점(development view)
  • 시스템을 구성하는 처리 장치 간의 물리적인 배치에 초점
  • 컴포넌트 다이어그램, 배치 다이어그램

 

• 아키텍처 스타일
  • data-centered 형(repository) 스타일, client-server 스타일, 계층(layer) 스타일, MVC 스타일, data flow 스타일 등
  • architecture style이 결정되면 SW 특성과 전체 구조, 개발 방법을 알 수 있다.
  • style에 따라 구조, 규칙, 요소, 기법 등이 결정됨
  • 좋은 SW architecture 설계
    • 원하는 SW를 만들기 위해 적합한 architecture style을 선택하고, 적용하고, 통합하는 것
      

      

  • 데이터중심형 스타일(data centered/repository)
    

    

    • 이 모델이 유용한 시스템: 대량의 데이터를 공유하는 급여 시스템, 은행 업무 시스템, 복잡한 자료가 계속 변경되는 업무를 처리 하는 응용 시스템
    • 장점
      • 데이터를 모순되지 않고 일관성 있게 관리
      • 새로운 sub-system의 추가 용이
    • 단점
      • repository의 병목 현상 → 높은 결합도
      • repository 변경 → sub-system의 영향
  • 클라이언트-서버 스타일(client-server style)
    

    

     
    • 여러 개의 클라이언트가 네트워크 통신을 활용해 서버에 접속을 하고 그 서버와 붙어있는 데이터베이스를 활용할 수 있는 시스템
    • 클라이언트와 서버 간의 상호작용을 기반으로 한 분산 시스템을 구축하는 방법
    • 네트워크를 이용하는 분산 시스템 형태
    • 데이터와 처리 기능을 client와 server에 분할하여 사용
      

      

    • 비중에 따른 client-server style
      

      

    • Thin client model
      • client: presentation 계층만 구현
      • server: 모든 응용 처리 및 데이터 관리 수행
      • 컴파일러처럼 데이터 관리가 거의 필요 없는 application
      • 응용 처리가 거의 필요 없는 data-intensive의 application
    • Fat client model
      • client: application logic 과 presentation의 많은 부분을 구현
      • client에 많은 부하가 걸린다.
      • client 컴퓨 사양이 application을 처리할 만큼 충분해야 한다.
      • server: 데이터 관리만 관여
      • Thin Client style보다 관리가 복잡하다.
      • 새 버전의 application이 출시되면 모든 client에 배포 및 설치 필요
  • repository style vs. client-server style
    • repository style: 하나의 프로세스에 의해서 관리됨
    • client-server style: 제한이 없음. 웹에서와 같이 단일 client가 수천 개의 서버로부터 데이터를 받을 수 있다.
  • 계층 스타일(layering style)
    • 기능을 몇 개의 계층으로 나누어 배치
      

      

      상호작용을 위해 계층간의 protocol을 정의 해야 함

      • 프레젠테이션(사용자 인터페이스) 계층 (= front-end)
        • client 계층
        • 사용자와 직접 만나는 화면에 해당
        • UI 지원
      • 비즈니스 로직(애플리케이션) 계층 (=middleware)
        • 기능 요구사항을 구현, Application logic을 실행
        • 어떤 형태의 데이터가 필요하고, 반환될 것인지 결정
      • 데이터(데이터베이스) 계층 (=back-end)
        • DB에 접근 → 데이터 처리 및 관리
        • 필요한 데이터 제공
    • 장점
      • 계층 간 역할이 명확 → 각 계층을 필요에 따라 쉽게 변경 가능 
      • 각 계층의 응집도 ↑ , 계층간 결합도 ↓
      • 연결된 계층의 인터페이스만 잘 만들면 특정 계층의 재사용 가능
  • MVC 스타일
    

    

    • 모듈화의 필요성
      • 하나의 모듈에 너무 많은 요소가 포함되면 관리 및 유지보수의 어려움
        → 기능별, 특성별로 모듈화 → MVC
    • Model sub-system
      • view/control sub-system과 독립되어 모든 데이터 상태와 logic을 처리
      • 특정 입출력 방식에 영향을 받지 않고 무언가의 호출에 응답만 함
    • View sub-system
      • 사용자와 직접 대화가 이루어지는 부분
      • 역할: 데이터를 사용자에게 보여줌
    • Controller sub-system
      • 역할: view와 model 사이에서 전달자
      • view나 model sub-system 입장 → cotrol sub-system만 알면 된다.
    • MVC 스타일의 처리 과정
      

      

    • MVC 스타일 방식
      • 모델1) JSP에서 출력과 로직을 모두 처리
        
        

        

        • controller 영역과 view 영역을 같이 구현하는 방식
        • 사용자의 요청을 JSP가 전부 처리한다.
        • 요청을 받은 JSP는 JavaBean Service Class를 사용하여 웹브라우저 사용자가 요청한 작업을 처리하고 그 결과를 출력한다.
      • 모델2) JSP에서 출력만 처리
        • 웹브라우저 사용자의 요청을 서블릿이 받고
        • 서블릿은 해당 요청으로 View로 보여줄 것인지 model로 보낼 것인지 판단하여 전송
        • HTML 소스와 JAVA소스를 분리해놓았기 때문에 모델1 방식에 비해 확장시키기도 쉽고 유지보수 또한 쉽다.
    • 장점
      • 관심의 분리 (View 와 model의 분리)
      • 변경으로 인한 영향의 최소화 
      • loosely coupling
    • 단점
      • 기본 기능 설계로 인한 class 수 증가 → 복잡도 증가
  • 데이터 흐름 스타일 (pipe and filter 구조)
    

    

    • 개념
      • 데이터 처리 과정을 여러 단계로 분할하고, 각 단계를 파이프라인으로 연결 → 데이터를 효율적으로 처리하는 방식
      • 데이터 스트림을 생성하고 처리하는 시스템에서 사용
    • 특징
      • 각 처리 과정은 필터 컴포넌트에서 이루어짐
      • 처리되는 데이터는 파이프를 통해 흐른다.
        

        

      • 사용자의 개입 없이 데이터를 변환하는 시스템에 주로 사용
      • pipe와 filter를 조합하여 만드는 architecture에 적합
      • 예) image processing system, compiler의 순차적인 변환 처리기, Unix의 shell
    • 장점
      • 개발 기간 단축 및 고품질의 소프트웨어 생산
      • 수월한 의사소통
      • 용이한 유지보수
      • 안정적 개발
      • 구축 전 시스템 특성에 대한 simulation 가능
      • 기존 시스템에 대한 빠른 이해 가능

---

02 클래스간의 관계

• 연관 관계(association relationship)
  • 양방향 연관 관계
    • class 간에 서로 message를 주고 받는 관계
      → 두 class는 message를 주고 받으며 이용하는 관계가 된다
      

      

  • 역할이 부여된 연관 관계
    

    

  • 다중 연관 관계
    

    

    • 다중성 표기
      

      

  • unidirectional association
    

    

    • '학생'은 '교수'를 알지만, '교수'는 '학생'을 모르는 관계
      → 두 클래스가 서로 아는 관계가 아니고, 한 쪽만 아는 관계
  • association class
    

    

    점선 표기

    • 두 개 이상의 class 사이의 연관 관계를 정의하는 class
    • 중간 table을 통해 many-to-many 연관 관계를 구현할 때 사용
    • 중간 table에 추가적인 정보가 필요하거나, 두 class 사이의 연관 관계를 더 자세히 표현해야 할 경우에 유용
• 일반화 관계 (generalization relationship)
  • 공통점을 가지고 있는 class들을 묶어서 새로운 class를 만들고 공통적인 이름을 붙인 것
    

    

  • 상속 구조
    • 개별 class와 공통 class 사이에 'is a kind  of' 관계가 성립되어야 한다.
• 집합 관계(aggregation relationship)
  • 상위 클래스가 하위 클래스들로 구성될 때의 관계
  • 'is composed of'가 성립되어야 한다.
    → 'has a' 관계
    → '부분-전체' 관계
  • 전체와 부분의 관계 모든 객체가 별개의 생명 주기를 가지며 독립적으로 동작한다. → 약한 결합 관계
    

    

• 합성 관계(composition relationship)
  • 전체 객체에 완전히 종속되어 독립된 객체로 존재할 수 없다.
  • 부분 객체는 전체 객체가 없어지면 같이 없어진다.
  • 모든 객체가 같은 생명주기를 가지고 있어 각각 독립적으로 동작이 불가능 → 강한 결합 관계
    

    

• 의존 관계(dependency relationship)
  • 상대의 메서드를 가지고 있다.
  • 매우 짧은 시간 동안 관계가 유지된다.
    

    

    

• 실체화 관계(realization relationship)
  • 인터페이스 클래스
    • 변수를 정의할 수 없다
    • 상속 관계를 맺을 수 없다
    • abstract method를 가지며 이 method에 대한 구체적인 실현은 sub-class에서 구현한다.
      → 실체화 관계