나빌레라의 프로그래밍하기 #7

7. 동사 명사의 정리
지난 글에서는 사용자 시나리오에서 동사와 명사를 아무 생각없이 기계적으로 분리하는 작업만 수행했다. 이번 글에서는 그렇게 분리한 동사와 명사를 무언가 프로그래밍의 재료로 사용가능한 정도의 의미를 가질 수 있는 존재로 만들기 위한 작업을 수행하는 과정에 대해서 이야기를 해 보겠다.

계속 강조하고 언급하는 내용이지만 이 글에서 수행하는 절차는 전혀 학문적으로 검증되지 않았고 완전하지 않다. 실제 프로젝트 작업을 진행할 때는 학문으로 정리된 정식 SE적 절차를 거쳐서 작업하는 것이 더 효율적이고 효과적이다. 다만 나는 그런 SE적 절차에 대해서 제대로 지원을 받을 수 없거나 혼자하는 프로젝트에까지 그렇게 팍팍한 기준을 적용하고 싶어하지 않는 사람들을 위해서 내가 일반적으로 혼자 프로그래밍하고 놀때에 작업하는 과정에 대해서 글로 가볍게 써 나가고 있는 것임을 확실히 인지하고 이 글을 읽어주기 바란다.

먼저, 지난 글에서 분석했던 명사와 동사를 모두 모아본다.

명사
사용자, 서비스, 게시판, 글, 아이디, 비밀번호, 이메일, 닉네임, 사용자, 글, 본문, 댓글, 본문, 제목, 내용, 길이, 150자, 댓글, 제목, 내용, 위, 아래, 최근글, 화면, 본문, 글쓰기폼, 게시판리스트, 맨위, 댓글, 글쓰기폼, 본문, 댓글, 리스트, 맨아래, 본문, 댓글, 글쓴사람, 글, 5분, 게시판, 남자게시판, 여자게시판, 사용자 정보, 성별 정보, 남자, 남자게시판, 여자, 여자게시판, 본문, 댓글, 본문, 10점, 댓글, 5점, 가입자, 활동점수, 남자, 여자, 게시판, 글, 10000점, 반대, 괜찮아보이는사람, 데이트, 이성, 데이트, 신청받은사람, 신청한사람, 타임라인게시판, 문자, 글, 두 사람, 현재, 데이트, 사람, 다른사람

동사
접속하다. 접속하다, 읽다, 쓰다, 쓸 수 없다. 가입하다, (정보를)받다. 가입하다., 로그인하다, 로그아웃하다. 로그인하다, (글을)쓰다. 구분하다. 구분하지않는다, 제한한다. 구분하지않는다, 오래되다, 뿌리다. 쓰다, 있다. 쓰다, 있다. 삭제하다. 쓰다, 수정하다, 수정할수없다. 나누다. 가입하다, (추가로)받다. 쓰다. 쓰다, 달다, 부여하다, 유지하다. 쓰다, 소비하다, 같다(==마찬가지다). 신청하다. 가능하다. 신청하다. 수락하다. 공유하다. 생성하다. 주고받다. 쓰다, 대화하다. 진행중이다. 신청할수없다.

꽤 많다. 그리고 중복을 제거 한다. 중복을 제거 할 때는 단순하게 단어가 같은 것들을 기계적으로 제거하는 방법과 의미상 비슷한 것들을 제거하는 방법을 같이 사용해야 한다. 그리고 명사의 중복을 제거하는 방법과 동사의 중복을 제거하는 방법은 약간 다르게 진행되어야 한다. 우선, 명사의 중복부터 제거한다. 명사의 중복을 제거하는 것은 쉽다. 기계적인 중복 제거와 의미적인 중복 제거로 쭉쭉 제거해 나가면 된다.

중복을 제거한 명사
사용자, 서비스, 게시판, 글, 아이디, 비밀번호, 이메일, 닉네임, 본문, 댓글, 제목, 내용, 길이, 150자, 위, 아래, 최근글, 화면, 글쓰기폼, 게시판리스트, 맨위, 맨아래, 글쓴사람, 5분, 남자게시판, 여자게시판, 사용자 정보, 성별 정보, 남자, 여자, 10점, 5점, 활동점수, 10000점, 반대, 괜찮아보이는사람, 데이트, 이성, 신청받은사람, 신청한사람, 타임라인게시판, 문자, 두 사람, 현재, 사람, 다른사람

그리고 동사의 중복을 제거한다. 동사의 중복은 명사처럼 단순하게 진행되지 않는다. 같은 동사라도 주어에 따라서 실제로 동작이 다르기 때문에 중복되는 동사는 어떤 주어에 대한 동사인지 구분을 하고 주어가 같을 때만 중복으로 판단하고 제거한다. 동사가 어떤 주어에 대한 동사인지를 판단하려면 지난 글에서 썼던 시나리오를 다시 봐야 한다. 이렇게 시나리오는 한 번 분석을 했다고 버리는 것이 아니라 개발 과정 전체에서 계속해서 참고하는 중요한 자료이다. 그래서 시나리오를 잘 작성하는 것이 중요하다고 내가 계속 강조하는 것이다. 특히 이 글에서처럼 SE의 지원을 받지 않는 혼자하는 프로그래밍 작업은 누군가 오류를 고쳐주거나 가이드해 줄 전문가가 없기 때문에 더욱 시나리오에 신경을 많이 써야 한다. 물론 이글을 읽는 분이 SE 전공이거나 SE 관련 지식이 풍부하신 분이라면 이 글 자체가 우습게 보일 수도 있을 것이다.

중복을 제거하면서 모든 동사에 주어를 달아 준다. 이후 프로그래밍 작업을 진행할 때 동사는 동사 자체만으로는 행동을 정의하는것이 모호해진다. 그래서 주어를 달아서 메소드로 변환 될 때 보다 명확히 변환 될 수 있도록 한다.

중복을 제거한 동사
서비스에 접속하다.
글을 읽다.
- 본문을 읽다.
- 댓글을 읽다.
쓰다,
- 본문을 쓰다
- 댓글을 쓰다
- 남자가 여자게시판에 쓰다.
- 여자가 남자게시판에 쓰다.
본문을 쓸 수 없다.
서비스에 가입하다,
가입자 정보를 받다.
서비스에 로그인하다,
서비스에서 로그아웃하다.
본문과 댓글을 구분하다.
구분하지않는다.
- 본문의 제목, 내용을 구분하지 않는다.
- 댓글의 제목, 내용을 구분하지 않는다.
본문, 댓글의 길이를 제한한다.
글을 쓴 시간이 오래되다,
화면에 뿌리다.
본문, 댓글을 삭제하다.
본문, 댓글을 수정하다,
본문, 댓글을 수정할수없다.
남자게시판, 여자게시판으로 나누다.
성별 정보를 추가로 받다.
활동 점수를 부여하다,
활동 점수를 유지하다.
활동 점수를 소비하다,
데이트를 신청하다.
데이트 신청이 가능하다.
데이트 신청을 수락하다.
타임라인 게시판을 공유하다.
타임라인 게시판을 생성하다.
대화를 주고받다.
현재 데이트를 진행중이다.

많이 정리가 된것 같지만 아직 프로그램의 재료로 사용하기에는 부족한 감이 있다. 사용자 시나리오를 다시 잘 읽어보면 동사도 두 가지 부류로 나눌 수 있다. 데이터를 만들어내는 메소드와 데이터의 값을 읽는 메소드이다. 이 두 부류도 또 세분할 수 있다. 데이터를 만들어내는 메소드는 값을 추가하는 메소드, 값을 변경하는 메소드, 값을 삭제하는 메소드로 나눌 수 있다. 데이터의 값을 확인하는 메소드는 데이터의 값을 읽어서 사용자에게 보여주는 메소드와 데이터의 값의 상태만 확인해보는 메소드로 나눌 수 있다.

데이터를 만들어내는 메소드
* 데이터를 추가
서비스에 접속하다.
쓰다,
- 본문을 쓰다
- 댓글을 쓰다
- 남자가 여자게시판에 쓰다.
- 여자가 남자게시판에 쓰다.
서비스에 가입하다,
가입자 정보를 받다.
서비스에 로그인하다,
서비스에서 로그아웃하다.
성별 정보를 추가로 받다.
활동 점수를 부여하다,
데이트를 신청하다.
타임라인 게시판을 생성하다.

* 데이터를 변경
본문, 댓글을 수정하다,
활동 점수를 유지하다.
활동 점수를 소비하다,
데이트 신청을 수락하다.

* 데이터를 삭제
본문, 댓글을 삭제하다.

데이터의 값을 읽는 메소드
* 값을 읽음
글을 읽다.
- 본문을 읽다.
- 댓글을 읽다.
화면에 뿌리다.
남자게시판, 여자게시판으로 나누다.
타임라인 게시판을 공유하다.
대화를 주고받다.

* 값의 상태를 확인
(이성 게시판엔) 본문을 쓸 수 없다.
본문과 댓글을 구분하다.
구분하지않는다.
- 본문의 제목, 내용을 구분하지 않는다.
- 댓글의 제목, 내용을 구분하지 않는다.
본문, 댓글의 길이를 제한한다.
글을 쓴 시간이 오래되다,
본문, 댓글을 수정할수없다.
데이트 신청이 가능하다.
현재 데이트를 진행중이다.

데이터를 만들어 내는 메소드와 데이터의 값을 읽는 메소드는 그 자체로 public 속성의 메소드가 될 것이고, 값의 상태를 확인하는 메소드는 private 속성의 메소드가 될것 같다. 아직은 확실치 않지만 현재까지 그렇게 될 가능성이 높다.

명사도 분류가 필요할 것 같다. 명사들을 정리하는 방법에도 여러가지 기준이 있겠지만 일단 나는 각 명사들간에 종속적 속성을 기준으로 생각해서 정리해 봤다. 각 명사들은 상하 포함관계가 있을 수 있고, 도출되어 나온 명사는 다른 명사의 제약사항으로 의미가 있는 것일 수도 있기 때문이다.

사용자,
- 사용자 정보,
-- 아이디,
-- 비밀번호,
-- 이메일,
-- 닉네임,
-- 성별 정보(남자, 여자,)
서비스,
게시판,
- 화면
-- 위: 글 목록의 위에 글쓰기 폼, -- 아래: 댓글 목록의 아래에 댓글 쓰기폼
- 게시판리스트
-- 본문 최근글(맨위),
-- 댓글 최근글(맨아래)
- 남자게시판, 여자게시판
- 타임라인게시판(문자 주고 받는 컨셉)
글,
- 본문, (제목 내용 구분안함, 길이 150자 제한)
- 댓글, (제목, 내용 구분안함, 길이 150자 제한)
- 글쓴사람 (삭제 가능, 5분 안에 수정가능),
활동점수
- 10점(본문 쓸 때)
- 5점(댓글 쓸 때),
- 10000점(이성 게시판에 쓸 때 사용)
데이트
- 괜찮아보이는사람,
- 이성, - 신청받은사람,
- 신청한사람,
- 두 사람,
- 현재(데이트 중)
- 다른사람

대략 위와 같이 명사도 정리된다. 괄호 안은 해당 명사의 제약 사항이다.

이번 글에서 정리된 동사와 명사는 데이터베이스 테이블과 객체의 속성과 메소드등을 설계하는데 필요한 중요한 재료가 된다. 당연히 여기서 정리한 동사와 명사만 사용해서는 설계와 프로그래밍을 할 수 없다. 중요한 재료가 된다는 것이 요점이다. 김치찌개를 만드는데 김치는 중요한 재료이지만 김치만 있다고 김치찌개를 만들 수 없다. 물도 있어야 하고 냄비도 있어야 하고, 가스, 가스렌지, 소금, 양념등 많은 부가적 재료들이 더 필요하다. 하지만 김치가 없으면 김치찌개 자체를 만들 수 없다. 오늘 글에서 정리한 명사와 동사들은 김치찌개에서 김치와 같은 존재라고 생각하면 이해하기 쉬울 것이다.

이렇게 글로 장황하게 썻지만 몇 번 해보다 보면 사용자 시나리오에서 다음 글에서 쓸 데이터베이스및 객체 설계를 곧바로 할 수 있게 된다. 회사같은 곳에서 작업하는 "중요하고 잘못되면 큰일나는" 프로그래밍이 아니기 때문에 제대로 하지 않아도 혼나지 않으니까 부담없이 자유롭게 시나리오를 쓰고 시나리오를 읽어가면서 실시간으로 데이터베이스 테이블 스키마가 도출된다. 단, 어떻게 그런것이 바로 이어지는지 모르는 사람들을 위해서 이렇게 그 과정을 풀어서 쓰는 것이다. 머릿속에서 빠르게 수행하는 것이긴 하지만 분명히 거쳐가는 과정이기 때문이다.

====
이 글은 CC이지만 다른곳에 불펌은 하지 말아 주세요. KLDP와 raonlife에(http://raonlife.com/navilera/blog/view/57/)만 연재합니다. 다른 곳에 연재되어 있는 것은 불펌이오니 저에게 알려주세요.