안녕하세요? 이번 글은 Bluemix를 이용하여 간단한 클라우드 애플리케이션을 디자인하고 만들어 가는 과정을 내용으로 연재되고 있습니다. 아래와 같은 순서로 진행되고 있으므로 참고 부탁 드립니다.


  1. 클라우드 환경 이해
  2. 애플리케이션 구상 및 요건 정의
  3. 요건에 대한 Usecase 및 Wireframe 작성
  4. 마이크로 서비스 아키텍쳐 설계
  5. 애플리케이션 서버 환경 준비
  6. 애플리케이션 로컬 개발 환경 준비
  7. 애플리케이션 프로토타입 작성 Part1
  8. 애플리케이션 프로토타입 작성 Part2
  9. 애플리케이션 프로토타입 작성 Part3
  10. 애플리케이션 DevOps 환경 구성

요건에 대한 Usecase 및 Wireframe 작성

지난 글에서는 아이디어를 구체화 하고 요건을 정리해 보았습니다. 이번 글에서는 해당 요건을 이용한 Usecase를 생성하고 이에 대응하는 Wireframe UI를 작성해 보도록 하겠습니다.

Usecase 작성

Usecase 작성은 요건으로 제시된 내용을 실제 애플리케이션 구현을 위한 설계 작업입니다. 개발하고자 하는 애플리케이션 또는 프로젝트 상황에 따라 Usecase 작성에 대한 가이드 라인이 있지만, 기본적으로 Usecase는 만들고자 하는 결과물의 기능을 사용자의 입장에서 설명하기 위한 사용 사례 로 볼 수 있습니다. 시스템의 기능을 정의하는 것이 Usecase의 궁국의 목적이지요. 비록 요건이 정의 되었다고는 해도 사람들마다 생각이 달라서 같은 글을 보고 서로 다른 모습으로 이해하는 경우가 많습니다. 따라서, Usecase의 작성은 다양한 사람들끼리 협업하는 과정에서 발생하는 의사 소통 문제를 줄여주고 개발에 필요한 것이 무엇인지 명확하게 알 수 있게 해 줍니다.

다음은 앞서 글에서 작성한 요건입니다.

  • 방문자 정보에 대해 수기가 아닌 전산으로 입력/관리해야 한다
  • 방문자의 보안 동의 및 정보 확인도 전산으로 입력 받을 수 있어야 한다
  • 방문자에 대한 정보 입력 시 방문자가 아닌 리셉셔니스트가 입력하고 이를 방문자에게 확인하는 형태가 되어야 한다
  • 보안 동의 서식이나 내용은 관리자에 의해 수정 가능해야 한다
  • 입력한 데이터는 쉽게 수정 할 수 있어야 한다
  • 과거 방문 내역이나 정보에 대해 손쉽게 확인 할 수 있어야 한다
  • 에스코트 직원 확인을 위해 정보(성명, 연락처 등)를 조회 할 수 있는 기능이 있어야 한다
  • 방문 예정자에 대한 사전 정보 등록은 에스코트 직원이 직접 할 수 있어야 한다
  • 에스코트 직원은 자신이 신청/등록한 정보를 바로 확인 할 수 있어야 한다
  • 사용자에게 부여된 권한에 따라 기능이 제한되어야 한다
  • 보관되는 데이터는 암호화된 형태로 보관되어야 한다

이제 작성한 요건을 만족하는 내용으로 화면/기능을 정의하여 이를 Usecase로 작성해 보도록 하겠습니다. 이 글에서는 리스트로 정리하지만 메모지나 화이트보드를 이용하여 그림을 그려가면서 정리하는 Usecase Diagram을 작성해도 상관 없습니다. 그림을 이용하면 글보다 직관적이라 미처 생각하지 못해 놓쳤던 부분을 찾게 되기도 합니다.

우선 사용자를 정리하여 Actor로 분류합니다.

  1. Actors
    • 리셉셔니스트 (Receptionist, Employee)
    • 에스코드 직원 (Escort, Employee)
    • 방문자 (Visitor, Guest)
    • 관리자 (Administrator, Employee)

초기 아이디어에서 이 애플리케이션을 사용하는 사람은 리셉셔니스트였는데 실제 요건과 기능을 정의하다보니 리셉셔니스트 말고도 추가된 사용자가 있는 것을 알 수 있습니다. 추가된 사용자는 미처 생각하지 못한 경우이지만 주요 기능은 리셉셔니스트를 위한 것이고 다른 사용자의 경우 기능을 제한하거나 운영관리에 필요한 기능이므로 큰 틀에서 벗어난 것은 아닙니다.

이제 사용자 별로 필요한 기능을 정리해 봅니다.

  1. 리셉셔니스트
    1. 로그인
    2. 방문 예정자 조회 (전체)
    3. 방문 예정자 정보 추가
    4. 방문 예정자 정보 변경
    5. 방문 예정 정보 취소
    6. 방문 기록 조회
    7. 임시 출입카드 발급
    8. 임시 출입카드 회수
    9. 로그아웃
  2. 에스코트 직원
    1. 로그인
    2. 방문 예정자 조회 (본인 담당)
    3. 방문 예정자 정보 추가
    4. 방문 예정자 정보 변경
    5. 방문 예정 정보 취소
    6. 방문 기록 조회
    7. 로그아웃
  3. 방문자
    1. 방문자 정보 확인
    2. 보안 서약 및 정보 제공 동의
  4. 관리자(운영자)
    1. 로그인
    2. 방문 예정자 조회 (전체)
    3. 방문 예정자 정보 추가
    4. 방문 예정자 정보 변경
    5. 방문 예정 정보 취소
    6. 방문 기록 조회
    7. 임시 출입카드 발급
    8. 임시 출입카드 회수
    9. 임시 출입카드 등록
    10. 임시 출입카드 정보 변경
    11. 임시 출입카드 삭제
    12. 사용자 권한 부여
    13. 보안 서약 및 정보 제공 동의 템플릿 변경
    14. 로그아웃

그리고, 필요한 기능을 잠깐 살펴보면 공통되는 내용이 상당 부분 있는 것을 알 수 있습니다. 이름이 동일한 경우라도 Actor에 따라 조금씩 다를 수 있으므로 잘 구분하여 Usecase를 작성해야 합니다.

일반적으로 Usecase에 포함되어야 하는 내용은 다음과 같습니다.

  • Usecase ID 또는 이름
  • Usecase 개요 (간단한 설명)
  • Actor (사용자)
  • 선행 조건 (이 Usecase를 시작하기 전에 갖춰져야 할 조건)
  • 후행 조건 (이 Usecase가 끝나고 나면 갖춰질 수 있는 조건)
  • 특별 요청 사항
  • 이벤트 흐름
    • 정상 흐름 – 수행 흐름 및 예상 결과
    • 대안 흐름 – 정상 수행이 안되는 경우 (예외 처리, 시스템 오류 등)

이 내용을 바탕으로 로그인에 대한 Usecase를 작성해 보도록 합니다.

Usecase ID SMV-UCS-001 Usecase Name 사용자 로그인
개요 가입된 사용자가 애플리케이션 사용을 위해 인증 정보를 입력하여 로그인한다
Actor 리셉셔니스트, 에스코트 직원, 관리자
선행 조건 Actor는 직원이어야 한다
후행 조건 사용자에게 부여된 권한 정보를 가진 로그인 세션이 생성되어야 한다
특별 요청 사항 없음
이벤트 흐름
정상 흐름
  • 로그인 성공
    1. ACTOR: 인증 정보(ID와 비밀번호)를 전송한다
    2. SYSTEM: 인증 정보가 맞는지 확인한다
    3. SYSTEM: 로그인 세션을 생성한다
  • 대안 흐름
  • 인증 정보가 없는 경우 “인증 정보를 입력해 주세요” 메시지를 보여주고 재입력을 요청한다
  • 인증 정보가 잘못된 경우 “인증 정보가 잘못 되었습니다” 메시지를 보여주고 재입력을 요청한다
  • Word나 Powerpoint와 같은 문서 형식으로 Usecase 만들면 눈에 잘 띄어서 편리하지만, 다른 사람들과 이 내용을 공유하고 또 편집하기에는 아무래도 여러가지 제약이 따르게 됩니다. 특히, GitHub와 같은 소스 저장소를 이용하여 협업을 진행하는 경우 binary 파일은 그 변경 내역도 추적 하기 어렵게 됩니다.

    만약 Usecase를 단순 Text를 이용하면서도 어느정도 형식을 갖춘 문서 작성이 가능한 Markdown 파일로 작성하고 이를 GitHub에 공유하여 사용한다면 보다 쉽게 접근할 수 있는 장점이 있습니다. 특히 GitHub는 웹에서 접근 할 때 Markdown 파일의 경우 GitHub style로 변환해서 보여줍니다.

    위의 로그인을 Markdown으로 작성하면 다음과 같습니다.


    # SMV-UCS-000-001-사용자_로그인
    
    ## 일반
    | Key   | 설명 |
    |-------| :-- |
    | ID    | SMV-UCS-000-001 |
    | Name  | 사용자 로그인 |
    | Actor | 리셉셔니스트, 에스코트 직원, 관리자 |
    
    ## 개요
    가입된 사용자가 애플리케이션 사용을 위해 인증 정보를 입력하여 로그인한다
    
    ## 조건
    ### 선행 조건
    * Actor는 직원이어야 한다
      
    ### 후행 조건
    * 사용자에게 부여된 권한 정보를 가진 로그인 세션이 생성되어야 한다
    * 로그인 직후 초기화면으로 이동 되어야 한다
    
    ### 특별 요청 사항
    * 없음
    
    ## 이벤트 흐름
    
    ### 정상 흐름
    * 로그인 성공
        1. ACTOR: 인증 정보(ID와 비밀번호)를 전송한다
        2. SYSTEM: 인증 정보가 맞는지 확인한다
        3. SYSTEM: 로그인 세션을 생성한다
    
    ### 대안 흐름
    * 인증 정보가 없는 경우 "인증 정보를 입력해 주세요" 메시지를 보여주고 재입력을 요청한다
    * 인증 정보가 잘못된 경우 "인증 정보가 잘못 되었습니다" 메시지를 보여주고 재입력을 요청한다

    본 글에 사용된 Usecase들은 Markdown 형식으로 작성하였으며, https://github.com/mc500/smv/blob/master/docs/Overview.md에서 확인 해 보실 수 있으니 참고하시기 바랍니다.

    Wireframe UI

    Usecase가 완성이 되었다면 이를 Wireframe GUI로 만들어 보도록 합니다. Usecase가 글로 작성된 기능 명세라면 Wireframe은 이를 사람들의 사용할 User Interface를 테마나 그래픽 효과 없이 단순하게 표현하여 애플리케이션의 기능이 표현될 화면에 대한 Mockup을 말합니다.

    Wireframe의 작성은 빠르게 의견을 받아 수정하기 위해 화이트보드나 메모지에 손으로 슥슥 그리는 방법을 이용하기도 하고, Wifreframe 작성 도구를 이용하기도 합니다만, 본 글에서는 메모지를 이용하여 만들어 보도록 하겠습니다.

    예상되는 화면은 다음과 같습니다.

    1. 로그인
    2. 방문 일정 조회
    3. 방문자 등록
    4. 방문자 상세정보
    5. 방문자 정보 확인
    6. 보안 서약 및 정보 제공 동의
    7. 임시 출입카드 조회

    그리고 이를 메모지에 간략하게 정의하는 것으로 Wireframe을 구성 했습니다. 메모지를 이용하면 애플리케이션의 Usecaes에 따라 flow를 직접 확인 해 볼 수 있는 장점이 있습니다. 또한 중복되거나 유사한 부분이 어떤지도 쉽게 찾을 수 있습니다.


    첨부된 그림을 보면 방문자 등록화면과 방문자 상세 정보 화면이 80% 이상 일치하는 모습입니다. 또한, 표로 구성된 부분도 아래 페이지 탐색 영역이 공통으로 사용되는 모습을 볼 수 있습니다. 나중에 실제 화면으로 구현 시 공통으로 작성할 수 있는 부분이 될 수 있는 것이 어디인지 미리 생각해 볼 기회가 되기도 합니다.

    작성한 Wireframe은 앞서 Usecase나 상세 동작에 대한 것을 담고 있지는 않습니만, 전반적인 애플리케이션의 화면을 정의 한 것이라 할 수 있습니다. 상세한 내용에 대한 부분은 프로토타입을 작성 할 때에 진행하게 됩니다.

    지금까지 Usecase와 Wireframe을 작성했습니다. 다음 글에서는 이 애플리케이션에 대한 마이크로 서비스 아키텍쳐 설계에 대한 내용을 다루도록 하겠습니다.


    1. 클라우드 환경 이해
    2. 애플리케이션 구상 및 요건 정의
    3. 요건에 대한 Usecase 및 Wireframe 작성
    4. 마이크로 서비스 아키텍쳐 설계
    5. 애플리케이션 서버 환경 준비
    6. 애플리케이션 로컬 개발 환경 준비
    7. 애플리케이션 프로토타입 작성 Part1
    8. 애플리케이션 프로토타입 작성 Part2
    9. 애플리케이션 프로토타입 작성 Part3
    10. 애플리케이션 DevOps 환경 구성

    참고

    토론 참가

    이메일은 공개되지 않습니다. 필수 입력창은 * 로 표시되어 있습니다