주식 자동매매 프로그램 (키움api) - Use Case Diagram

본 포스팅이 조금이나마 도움이 되셨다면 공감버튼 클릭 부탁드립니다.

 

지난 글 키움 주식 자동매매 프로그램 요구사항 분석 (190620)에서 주식 자동매매 프로그램을 만들기 위한 요구사항에 대해 정리를 했었고, 이번에는 요구사항을 기반으로 간단히 use case diagram 을 만들어봤습니다.

 

Use Case Diagram

위 그림에서 가운데 있는 System이 주식 자동매매 프로그램이고, 이 프로그램을 사용하는 Actor는 실제 매매를 수행할 사용자(user)와 프로그램을 유지보수할 개발자(developer)로 정의했습니다. 위 그림에서 시스템은 다시 서브시스템으로 나뉘어야 하지만(구현관점), 사용자가 바라보는 측면에서는 단일 시스템이기 때문에(실사용관점) 그냥 하나의 box 로 추상화 하여 표현했습니다. System Architecture Design 단계에서 서브시스템을 정의하고 각각의 시스템간의 관계를 그려주면 될것 같습니다.

 

Use Case 상세화 단계

System 내부에 여러개의 타원은 Use Case 를 의미합니다. 각각의 Use Case는 시스템에서 제공해야 하는 기능이 됩니다. Use Case를 작성하다보니 Use Case를 좀더 상세하게 나눠야 하는것이 아닐까? 라는 생각이 들기도 했지만, 모든 Use Case에 대해서 좀더 상세한 단계까지 작성하게 되면 Use Case Diagram이 복잡해보이는 문제도 있고, 사용자가 시스템을 사용하는 핵심 Use Case가 무엇인지 잘 보이지 않을것 같아서 위 그림과 같이 작성을 했습니다. 만약 Use Case를 좀더 상세화 하는것이 가치가 있다면 Use Case Diagram의 상세화 단계를 레벨링해서, 위 그림을 Level1 Diagram 으로하고 상세하된 Use Case Diagram 을 Level2 Diagram 으로 관리하면 되겠습니다. 어떤 Use Case 는 다른 Use Case와 의존성이 있기도 하고, 독립적인 Use Case 도 존재합니다. Use Case 를 실제 구현하는 관점에서 좀더 상세화하여 패키지, 클래스, 함수 단위로 SW설계를 해야하는데, 이때 각 Use Case 의 의존성을 고려하여 설계에 반영해야 하겠습니다.

 

 

Use Case 를 만드는 기준

지난 글에서 요구사항이 굉장히 많았는데, Use Case Diagram을 그릴때 시스템의 기능(Feature)관점으로 정리를 했습니다. 예를 들어 아래의 요구사항들은 기능(Feature) 관점에서 보면 모두 주식관련 데이터 수집이라고 표현할 수 있습니다.

• 데이터 수집은 자동화 되어야 한다.
• 주식 정보 + 회사 회계 정보가 상세하게 수집되어야 한다. (금융감독원 사이트에서?)
• 해외 증시 데이터도 수집해야 한다 (미국, 중국, 일본의 주식, 선물, 옵션)
• 주요 뉴스도 시계열 데이터로 저장해야 한다. (Global 이슈, 국내 정치, 사회, 경제 이슈 등등)

 

요구사항에 보면 비기능 측면의 요구사항도 있습니다. 아래의 것들은 실제 시스템의 기능과는 상관이 없습니다.

• 암호와 같이 개인정보는 git 으로 관리되면 안되고, 로컬에서 관리 될 수 있도록 해야 한다.
• 프로그램이 해킹당하면 안된다.
• jenkins + github 연동하여 프로그램 Q Test (정적분석, coverage, pep8, 유닛테스트) 를 수행해야 한다.
• 요구사항( ?? ) -- 커밋(github) -- 이슈(github) 추적성이 관리 되어야 한다.

이러한 비기능 요구사항에 대해서는 SW 상세설계(HLD, LLD 또는 SAD, SDD라고 부르기도 함) 단계에서 요구사항이 만족될 수 있도록 반영을 해야겠습니다. 비기능 요구사항은 어떻게 관리를 하는지 구글링을 해보니 비기능 요구사항은 Use Case 로 표현할 수 없고 SW 아키텍쳐에 반영한다는 내용을 찾을 수 있었습니다. 실제로 제가 생각한 것과 동일하네요! (당연한 결과일 수 있습니다)

 

 

마무리

사용자 요구사항 분석을 바탕으로 Use Case Diagram 을 그려보니, 내가 만들어야 할 시스템은 어떤 컨셉인지 좀더 명확해지는 효과가 있었습니다. 어차피 제가 만드는 시스템이니 저는 금방 컨셉이 이해가 되지만, 이 프로그램을 누군가에게 설명한다고 했을 때 설명하기도 쉽고, 서로간에 miss communication 되지 않고 명확히 내용을 전달하는데 효과적일 것이라는 생각이 들었습니다. 다음으로는 Use Case Diagram을 기반으로 SW 설계를 시작해야 합니다. 먼저 System Architecture Design 을 해야 합니다. HW 는 어떻게 구성할 것인지, SW 는 어떻게 구성할 것인지 설계해야 합니다. 일단 제가 만드는 주식 자동매매 프로그램의 경우 일반 PC에서 수행되는 어플리케이션이기 때문에 HW에 대한 설계는 하지 않아도 됩니다. 자동매매 프로그램을 구성하는 서브 시스템을 정의하고 각각의 서브시스템의 역할과 관계를 도식화 해볼 예정입니다.

 

 

용어설명

1. HLD: High Level Design
2. LLD: Low Level Design
3. SAD: Software Architectural Design
4. SDD: Software Detailed Design

 

참고링크

Use Case Diagram 모델링하기

Use Case Diagram - 요구사항부터 구현까지

유스케이스와 UML

 

본 포스팅이 조금이나마 도움이 되셨다면 공감버튼 클릭 부탁드립니다.