오늘 하루종일 찾다가 질문을 올립니다. 
Forms.py에 2번째 라인 Model 을 import 하는 부분에서 계속 적으로 에러가 발생합니다. 
잘 작동되다가 어느순간부터 importerror가 나는데, 쉽게 잡힐줄 알았던 에러가... 답이 안보이네요.
* 파일들은 모두 같은 디렉터리 안에 있습니다. 

Forms.py // 2번째 라인 문제

from django import forms from . models import CompanyModel #CompanyModel이 임포트가 안됨. class CompanyForm(forms.ModelForm): class Meta: model = CompanyModel fields = ["cmp_name", "cmp_email", "cmp_descript", "slug"] def clean_cmp_name(self): cmp_name = self.cleaned_data.get('cmp_name') # write validation code. return cmp_name

Models.py 
from django.db import models
from django.urls import reverse
from django.db.models.signals import pre_save, post_save
from django.utils.text import slugify
from .views import CmpDetail

# Create your models here.

class CompanyModel(models.Model):
    cmp_name = models.CharField(max_length=100)
    cmp_descript = models.TextField()
    cmp_email = models.EmailField()
    slug = models.SlugField()
    updated = models.DateTimeField(auto_now_add=True, auto_now=False)

    class Meta:
        odering = ["-updated"]

    def __str__(self):
        return self.cmp_name

    def get_absolute_url(self):
        return reverse("CmpDetail", args={"slug":self.slug})

View.py

from django.shortcuts import render
from .forms import CompanyForm
from .models import CompanyModel
from django.contrib.auth.decorators import login_required
from django.views.generic.base import TemplateView
from django.views.generic.detail import DetailView
from django.views.generic.list import ListView


class CmpDetail(DetailView):
    model = CompanyModel

class CmpListView(ListView):
    model = CompanyModel

    def get_queryset(self, *args, **kwargs):
        qs = super(CmpListView, self).get_queryset(*args, **kwargs)
        print(qs)
        print(qs.first())
        return qs

ERRORPAGE : Models.py가 임포트가 안된다는것 같은데... 답이 없네요. 

  

 File "", line 994, in _gcd_import
  File "", line 971, in _find_and_load
  File "", line 955, in _find_and_load_unlocked
  File "", line 665, in _load_unlocked
  File "", line 678, in exec_module
  File "", line 219, in _call_with_frames_removed
  File "c:\Projects\keras_talk\My_Django_Stuff\djmod\company\models.py", line 5, in 
    from .views import CmpDetail
  File "c:\Projects\keras_talk\My_Django_Stuff\djmod\company\views.py", line 2, in 
    from .forms import CompanyForm
  File "c:\Projects\keras_talk\My_Django_Stuff\djmod\company\forms.py", line 2, in 
    from . models import CompanyModel
ImportError: cannot import name 'CompanyModel'

좋은 의견 있으면 부탁드립니다. 





AskDjango의 이진석 님께서 답변을 주셨습니다. 

에러는 생각 이상으로 쉽게 잡혔네요... 


Models.py에 


from .views import CmpDetail 부분을 참조 시킨것에서 문제가 발생 했습니다. 

순환참조라고 하는데... 파이썬에서는 기능들을 이것저것 막 가져다 붙이면 문제가 발생하는 군요.. ㅋ 


혹시 ImportError가 발생하였다면 모델.py에 필요없는 부분이 임포트가 되었는지 확인해 보시기 바랍니다. 


from .views import CmpDetail




▶ 상태 다이어그램(State Diagram)이란 ?

사건이나 시간에 따라 시스템 객체 상태 변화를 표현한 그림. "단일 객체"의 상태를 나타냄. 시스템의 변화를 잡아내기 위하여 사용. 분석가, 설계자, 개발자 들이 시스템 내의 객체 행동을 이해하는데 큰 도움을 줌.


◎상태 다이어그램의 중요성

- 한 객체에서 일어날 수 있는 모든 변화의 양상을 잡아내어 모델링 함. 분석가, 설계자, 개발자들이 시스템내의 객체 행동을 이해하는데 도움을 줌. 클래스 다이어그램이 정적인 모습을 보여주는데 반해, 상태 다이어그램은 각 객체의 행동의 동적인 상황을 보여줌. 개발자 입장에선 각 객체들이 어떻게 행동하는지 쉽게 정확히 파악할 수 있게 만듦으로써 객체 구현에 있어서 고민을 덜어줌.


표현 

- 상태의 표현 : 모서리가 둥근 사각형으로 표현

- 상태 전이의 시작점 : 속을 칠한 원으로 표현

- 상태 전이의 종료점 : 속을 칠한 원을 둘러싼 원으로 표현 

- 상태 전이선 : 화살표 머리가 달린 실선


◎ 상태 아이콘에 넣는 정보

이름, 속성, 오퍼레이션의 세 영역으로 나누어 상세한 정보를 넣을 수 있다. 


이름 - 상태 이름 (필수) 

속성 - 상태 변수 (옵션) : 타이머나 카운터 처럼 상태 진행에 도움을 주는 데이터

오퍼레이션 - 활동(Activity - 옵션) : 사건(Event)과 동작(action)으로 이루어짐

예) 팩스 기계의 상태 정보의 표현과 전이

◎ 상태전이 선에 추가되는 정보 : 사건과 동작

사건(촉발사건 - Trigger event) : 전이가 일어나는 원인을 제공

연산(동작 -action) 실제로 수행되어 상태변화를 일으키는 연산


사건과 동작은 상태 전이 선에 가깝게 붙여준다. '/'을 사용하여 사건과 동작을 구분시킨다. 

◎ 상태 전이 선에 추가되는 정보 : 전이조건

어떤 조건에 따라 상태가 전이 될 때. 

조건에 따른 상태 전이의 분기가 일어날 때.

'[ ]' 를 사용하여 조건을 명시함

 

예) 앞의 GUI예에서 어떤 조건을 만족하면 스크린 세이버가 작동하는 상태로 됨.

◎ 하위상태 : 상태안에 상태가 있을때, 안에 있는 상태를 말함.


◎ 순차적 하위상태

- 하위 상태의 전이가 순차적으로 이루어짐. 

예) 앞의 GUI 예제에서 [작동] 상태의 하위 상태 전이를 나타낸다. 즉, [작동] 상태인 동안 사용자의 입력을 화면에 표현하는 하위 상태들의 전이 과정을 표현한 것이다. 

◎ 동시적 하위상태

- 하위 상태의 동시 진행성을 표현

동시 진행하는 순차적 하위 상태를 점선으로 구분지음

예) 위의 GUI 예제에서 "사용자 입력을 화면에 표현"하는 하위 상태전이 단계와 더불어 "시스템 내의 시간을 정해진 간격마다 화면에 표현" 하는 또 다른 하위 상태 전이가 일어나는 과정을 나타냄.

즉, 우리가 워드를 치는 동안 윈도우의 "시작 메뉴바" 오른쪽에 시계는 분 마다 바뀐 값을 표현하는 것을 말함

◎ 이력상태 (History State) 

주어진 객체가 복합 상태를 벗어날 때 활성중인 하위 상태를 기억해 두는 상태.


표현 : 원으로 둘러싸인 "H"문자로 표현

예) GUI 작동 중 일정 시간에 의해 스크린 세이버가 작동하다가 다시 원 상태로 되돌아 올 때 이전의 기억된 상태로 되돌아 오는 것을 나타냄


◎ 메시지와 신호 (Message & Signal)

메시지 : 한 객체가 다른 객체에게 전송하는 메시지 즉, 상태전이를 일으키는 촉발 사건을 말함

신호 : 메시지를 받는 객체의 상태 다이어그램에서 전이를 촉발시키는 메시지를 말함.

신호객체 (Signal Object)는 속성을 가지고 있다. 신호는 객체이기 때문에, 기존의 신호를 상속받아 새 신호를 만드는 일도 가능하다.



장고를 나도 처음 사용해 보는 거라 Registration Redux를 적용할때 참... 이해가 가지 않는 몇몇 부분이 있다. 이번에도 register부분에서 에러가 났는데, 해결방법은 이것저것 찾아보니 Setting에 Email 세팅을 안했더라...


Setting.py

EMAIL_BACKEND = 'django.core.mail.backends.console.EmailBackend' 를 추가 


Register 를 등록할떄 왜 Email 셋팅이 필요한가 했는데... 가입을 할 때 Email 인증이 필요하기 때문.



이후 관리자 페이지에서 해당 아이디에 대한 인증값을 복사한뒤

 

http://127.0.0.1:8000/accounts/activate/17d2f950ecf031a0d939bfb854703a669eebef97


해당 계정을 활성화 시키면 됨. 

이 과정은 아마도 계정 이메일을 셋팅하고 설정을 하면 되지만, local 단계에서는 이해정도로 빨리 습득을 해야 하기 때문에 실제 이메일 Sent는 하지 않았음.



참... 편리하게 만들어놨네.


시퀀스 다이어그램이란 ?

 상태 다이어그램이 촉발 사건에 따른 단일 객체의 상태변화를 표현한 것이라면, 시퀀스 다이어그램은 어려 객체들이 시간 경과에 따라 객체 상호간 교류 과정을 표현한 것.


구성

- 객체 (Object) : 사각형으로 나타내며 밑줄이 들어가 있다. 

- 메세지 (Message) : 실선 화살표로 그려진다

- 시간 : 진행 상황을 나타내기 위하여 수직선으로 그린다. 


객체 

 시퀀스 다이어그램의 가장 윗 부분에 위치, 왼쪽에서 오른쪽으로 배열한다. 배열 순서는 다이어그램을 간략하게 하는 방향으로 기준을 삼는다. 각 객체로부터 아래로 뻗어가는 점선은 객체의 생명선(lifeline)이라 불린다. 생명선을 따라 좁다란 사각형이 나타나는데, 이 부분을 실행(activation)이라 한다. 즉, 객체가 수행되고 있음을 나타낸다. 사각형의 길이는 오퍼레이션 실행 소요 시간을 나타낸다. 


메시지

한 객체에서 다른 객체로 전송

한 객체의 생명선에서 다른 객체의 생명선으로 이동하는 것으로 표현

객체는 자기 자신에게 메시지를 보낼 수 있다. 


종류

- 단순 (Simple) 메세지 - 한 객체에서 다른 객체로 제어 흐름이 이동하는것. 

- 동기 (synchronous) 메세지 - 메세지 전송 후 수신 객체로 부터 그 메세지를 받았다는 답변이 와야 자신의 작업을 계속 할 수 있음.

- 비동기(asynchronous) 메세지 - 메세지 전송 후 수신 객체로 부터 답신을 기다리지 않고 작업을 계속 진행함. 


표기

시간 

- 시간을 수직 방향으로 표현한다. 

- 시간의 흐름은 위에서 아래로 흐른다.

예제) State Diagram의 GUI 시스템 예에서 GUI가 다른 객체들과 어떻게 교류를 하고 시간에 따라 작동을 하는지 알아보자. 


1. GUI는 키 입력을 운영체제에 알린다. 

2. 운영체제는 CPU에게 그 사실을 알린다. 

3. 운영체제는 GUI를 갱신한다. 

4. CPU는 비디오 카드에게 GUI 갱신에 필요한 명령을 내린다.

5. 비디오 카드는 모니터로 메시지를 전송한다.

6. 모니터는 화면에 Alpha Numberic 문자를 표시하고, 사용자에게 피드백을 제공한다. 

다음은 USECASE Diagram에서 Sequence Diagram으로 접근한 예.

USECASE 다이어그램에서 나온 "음료수 사기"의 예를 시퀀스 다이어그램에 적용한다. 


객체를 골라내면

- 프론트 : 음료수 자판기가 고객과 대화하는 유일한 인터페이스, 판매기 앞판에 있음

- 금전 등록기 : 돈을 체크하고 등록함.

- 디스펜서 : 음료수를 따르고 내어줌


처리과정을 작성해보면 다음과 같다. 


1. 소비자가 자판기의 프론트 앞에서서 투입구에 돈을 넣는다 (Insert)

2. 소비자가 마실 음료수를 고른다. (Select)

3. 돈이 금전 등록기에 들어간다. (Send)

4. 등록기는 선택된 음료가 디스펜서에 들어 있는지를 체크한다. 

5. 선택된 소다가 준비되어 있고, 등록기는 현금 잔고를 갱신한다. 

6. 등록기는 디스펜서를 사용하여 소다를 자동 판매기의 프론트로 보낸다.


이 예는 "음료수 사기" 쓰임새에서 단지 한개의 시나리오 (즉, 하나의 인스턴스에 대하여 그려지기 때문에, 이 다이어그램을 인스턴스 시퀀스 다이어그램 이라고 불린다. 

예제) "음료수 사기" 쓰임새에서 우린느 또 다른 시나리오를 가정할 수 있다. 선택된 음료수가 다 떨어진 경우 또는 소비자가 넣은 돈이 음료수 값과 맞지 않을 때, 이런 모든 경우를 하나의 시퀀스 다이어그램에 표현하고자 할 때 일반 시퀀스 다이어그램을 그리면 된다. 다음은 '액수에 맞지 않는 경우' 의 시나리오 이다.


1. 등록기는 소비자가 투입한 돈의 액수(input)가 음료수의 값(Price)와 맞는지 체크한다. 

2. 만일 액수가 음료수 값보다 많으면, 등록기는 차액을 계산하고 그 만큼의 현금 잔고가 있는지 체크를 한다. 

3. 만일 차액 만큼 현금이 잔고 (Cash reserve)에 남아 있다면, 등록기는 거스름돈(change)을 내어주고 나머지 동작은 그 전과 똑같이 진행한다.

4. 만일 차액 만큼의 현금이 잔고에 남아 있지 않으면, 등록기는 소비자가 투입한 돈을 그대로 돌려주고 "잔액이 부족합니다." 란 메세지를 표시한다.  

5. 만일 소비자가 투입한 돈의 액수가 음료수값보다 적으며, 등록기는 아무것도 하지 않고 돈이 더 들어올때 까지 대기한다. 


* 조건문을 표현하기 위해서는 대괄호 [ ] 안에 조건을 써주고, 이것을 메세지 화살표 위에 놓으면 된다.


▶ '액수가 맞지 않는 경우' 의 시나리오

예) "선택된 음료수가 떨어진 경우"의 시나리오


1.  소비자가 다 팔린 브랜드의 음료수를 선택한 후, 음료수 자판기는 "다팔렸음" 메세지를 표시한다.

2.  음료수 자판기는 다른 브랜드를 선택하라는 메세지를 표시한다. 

3. 이 때 소비자는 투입한 돈을 돌려 받을 수 있는 버튼 누를 선택권을 가진다.

4.  만일 소비자가 현재 자판기에 남아있는 음료의 브랜드를 선택(Selection in Stock), 하게 된다면 투입한 돈이 맞았을 경우 모든 과정이 시나리오 대로 진행된다. 그렇지 않다면, 음료수 자판기는 "액수에 맞지 않는 경우" 시나리오 대로 진행한다. 

5.  만일 소비자가 또 고른 음료수의 브랜드가 품절 상태라면, 현재 남아 있는 음료의 브랜드를 소비자가 선택하던지 돈을 돌려 받는 버튼을 누를때 까지 전 과정을 반복한다.


▶ "액수가 맞지 않는 경우" 시나리오와 "선택된 음료가 떨어진 경우"의 시나리오가 모두 추가된 상태의 자판기 Sequence Diagram

시퀀스 내에서 객체 생성

- 기존의 객체 표현 방법처럼, 이름이 붙은 사각형으로 표현

- 보통의 객체처럼 시퀀스 다이어그램의 위에 두지 않는다.

- 생성된 객체는 이것이 생성된 시간과 대응이 되는 위치에 놓는다. 


이 객체를 생성한 메세지는 "create()"라는 레이블이 붙으며, 여기서 ()는 오퍼레이션을 의미한다. → <<create>> 스테레오 타입을 사용할 수도 있다. 


* while 문의 표현

 조건의 표현인 [ ] 왼쪽에 '*"를 붙인다. 

Recursion 나타내기

객체가 자기 자신을 호출하는 구조의 오퍼레이션을 가지는 경우가 있는데, 이러한 오퍼레이션을 Recursion 이라고 한다. 


예제) 어떤 시스템에 계산기 객체가 포함되어 있다고 하자. 이 객체의 오퍼레이션 중 하나가 이자(interest)를 계산하는 것이라고 가정하고, 지난 기간을 모두 종합한 복리(compound interest)를 계산하기 위해 이 계산기 객체의 오퍼레이션은 각 기간의 복리를 사용하여 계속 자신을 호출해야 한다. 이것을 다음 Sequence Diagram으로 표현하면 다음과 같다. 


표현

 실행 사각형에다가 작은 사각형을 그리고, 오퍼레이션을 나타내는 메시지 화살표를 실행 사각형에서 작은 사각형 쪽으로 향하도록 그린다.


쓰임새 (USE CASE) 란 ?

시스템의 사용에 대한 시나리오의 집합


목적

- 사용자의 관점에서 시스템을 모델링하기 위함. 즉, 사용자가 시스템에 대하여 바라는 바를 표현함으로써 사용자의 시점을 빨리 이해하고 쓸모있고 (Useful), 쓸 수 있는 (Useable) 시스템을 만들 수 있도록 함.


사용 

- 대게 의뢰인과 개발팀이 참조하는 설계문서의 한 부분으로 사용.

- 새로 만들어진 시스템을 테스트하는데 사용 : 사용자의 시스템 사용 시나리오를 표현한 것이기 때문에 테스트도 그 시나리오에 따라서 하면 됨


시스템 분석가와 사용자 힘을 합쳐 시스템의 사용 방법을 결정하는데 도움이 된다. 시스템이 가진 User Interface 설계 & 프로그래밍 방식에 매우 도움이 되는 다이어그램

[요구사항 수집]의 "시스템 요구사항 파악"의 과정과 [분석]과정에서의 출력물 → 사용자와의 대화를 통하여 얻어낸 정보를 표현한다. 



▶ USE CASE 의 분석과정 및 사용 방법 : 사용자를 만나 의견을 듣는것으로 시작 

1. 시스템 사용자를 시스템 분석과 설계의 초기 단계에 참여시킴

2. [요구사항 수집] 의뢰인과 대화 → 초기 클래스 다이어그램 → 사용하고 있는 용어를 통해서 개념정리 → 사용자 와의 대화가 유연해짐 

3. 사용자와 대화 → 설계하고자 하는 시스템을 가지고 어떤 일을 하는지 질문 → 얻어낸 대답은 미래에 USE CASE 다이어그램을 만드는대 토대로 사용

4. USE CASE 에 대한 간단한 설명을 붙임 → 설명이 많을 수록 사용자와 할 수 있는 대화의 밀도도 높아진다. 


USE CASE 의 재사용을 위한 방법 : 

- 포함(inclusion) : 다른 쓰임새를 구성하는 하나의 진행 과정으로 쓰임새를 사용.

- 확장(extension) : 기존의 쓰임새에 몇 개의 단계를 추가하여 새로운 쓰임새를 만듦.


※ USE CASE 만들때 주의사항

 - 해당 시나리오를 시작할때 만족 되어야 하는 선행조건

 - 시나리오가 완료될 때 만족되어야 하는 종료조건




행위자 (Actor)

시스템과 교류하는 사람이나 시스템 또는 장치, UseCase를 시작시키고, 구성하는 진행단계가 끝나면 그 결과를 받는다. 막대기로 사람모양을 표현, 행위자의 이름은 막대인간 아래에 쓴다. 


쓰임새 (UseCase) 

타원으로 표현, 쓰임새의 이름은 타원 안쪽 또는 아래에 쓴다. 쓰임새를 시작시킨 행위자는 왼쪽, 결과를 받는 행위자는 오른쪽에 표현. 행위자와 쓰임새 간의 연결은 실 선으로 그림. 


시스템 

쓰임새를 둘러싸는 사각형으로 표현, 행위자는 대게 시스템 외부에 있는 반면, 쓰임새는 시스템 내부에 존재한다. 즉, 쓰임새분석을 통하여 시스템과 외부세계와의 경계를 효과적으로 보여줄 수 있다.



[시나리오의 진행단계 나타내기]


- 쓰임새는 시나리오로 진행되며, 각 시나리오는 진행단계로 이루어진다. 

- USECASE를 구성하는 시나리오는 각각의 USECASE 다이어그램의 페이지에다가 텍스트로 적어둔다. 

- USECASE 다이어그램에  Note를 붙임으로써 표현할 수 있지만, 너무 지저분하게 보인다면 다이어그램의 생명인 '명확성'을 잃어버릴수 있다. 


 작성요령

1. USECASE를 시작하는 ACTOR

2. USECASE가 시작하는데 필요한 선행조건

3. 시나리오의 진행단계

4. 쓰임새가 끝나는데 필요한 종료조건

5. 쓰임새의 결과를 받는 행위자

6. 쓰임새의 가정 - Ex) "한번에 소비자 한명이 음료수 자판기를 사용한다" 등..

7. 간단한 한 문장 정도의 설명문


포함(Include) - 쓰임새가 다른 쓰임새를 포함하는 관계

 여러 쓰임새에서 공통으로 중복되는 시나리오가 있다면 이 시나리오를 따로 분리하여 새로운 쓰임새로 만들고 , 새로 만든 쓰임새를 각 쓰임새 마다 포함시키면 됨. 사용하려는 쓰임새가 사용되어지는 쓰임새를 필수적으로 포함해야 한다. 


포함된 쓰임새는 절대로 단독으로 존재할 수 없으며, 전체 쓰임새의 부분으로만 존재한다. 


표현

- 포함관계에 있는 쓰임새 사이를 쇄선으로 잇고, 포함되어지는 쓰임새 쪽에 화살표 머리를 둔다.

연결선 위에는 스테레오 타입 <<include>>를 붙인다. 


Ex) 자판기 내용물 공급자와 수금원이 포함된 자판기 시스템의 USECASE 다이어그램

→ "내용물 보충하기" 쓰임새와 "수금하기" 쓰임새 시나리오에서 공통으로 중복된 보안장치 해제나 보안장치 관련 설정과 관련된 진행 단계들을 따로 떼어내서 새로운 쓰임새로 만들고 포함시켰다. 



확장(Extend) - 쓰임새와 그 쓰임새를 확장한 확장 쓰임새의 관계

쓰임새의 시나리오에서, 어떤 조건에 따라 특정한 진행 단계의 행위를 확장하고자 다른 쓰임새를 참조하는 것을 말함. 이 때 확장 용도로 사용하기 위하여 참조되는 쓰임새를 '확장 쓰임새' 라고 함. 이 확장 쓰임새를 참조하는 쓰임새를 기본(Base) 쓰임새라 한다. 확장 쓰임새를 참조하는 시나리오의 특정한 진행단계를 확장포인트(extend point)라 한다. 즉, 특별한 조건에서만 수행되는 부 흐름부를 모형화 한 것으로, 어떤 조건이 부합되어야만 포함되는 쓰임새를 표현한다. 


따라서, 포함 관계의 쓰임새와 달리 확장 쓰임새와의 관계는 선택적이다. 

※ 기본 쓰임새에서 특정한 시나리오의 진행 단계의 확장이기 때문에 확장된 쓰임새는 절대로 단독으로 존재할 수가 없다.


표현   

두 쓰임새 사이를 쇄선으로 잇고, 기본 쓰임새 쪽에다가 화살표 머리를 둔다. 연결선 위에는 스테레오 타입 <<extend>> 를 붙입니다. 


예) 음료 자판기의 "내용물 보충하기" 쓰임새에서 각 음료수 마다 판매실적이 엇 비슷할 때는 문제가 없지만, 만약 음료수 마다 판매실적이 두드러지게 차이가 난다면, 우리는 판매실적이 따라 채우는 음료수의 양을 달리해야 할 것이다. 즉, 특정한 조건(판매실적 차이가 클 때) 이 만족 되었을 때 판매실적에 따라 달리 보충하도록 기존의 "내용물 보충하기" 쓰임새를 확장한 "판매실적에 따라 보충하기"라는 새로운 쓰임새를 만들고 확장관계를 가지게 했다. 


일반화 (Generalization) 


- 쓰임새를 상속하는 것을 의미 

- 상속을 해주는 쓰임새를 "부모 쓰임새"라 하고, 상속을 받는 쪽을 "자식 쓰임새"라고 한다. 

- 자식 쓰임새는 부모 쓰임새의 모든 행동과 의미를 물려 받으며, 여기에 자신만의 행동을 추가 할 수 있다. 

- 부모 쓰임새가 등장하는 곳에 자식 쓰임새를 대신 놓을 수 있다. 

- 두 쓰임새 사이를 실 선으로 연결하고, 부모 쓰임새 쪽에 속이 빈 화살표 머리를 붙인다. 

- 일반화 관계는 행위자(Actor)사이에도 적용할 수 있다. 

- 예) "음료수 사기" 쓰임새에서 상속받은 "음료수 자~알 사기" 쓰임새가 있다. 이 자식 쓰임새에는 "음료수 사기" 쓰임새의 모든 행동과 의미를 사지고 있고 추가적으로 '얼음추가', '여러 음료수 혼합하기' 등의 행동을 갖을 수 있다. 


예) 음료를 보충하는 '공급자'가 있고 수금을 하는 '수금원'이 있다. 그러나, 이 두 행위자 모두 음료수 제공 업체 직원으로 볼 수 있다. 


그룹화

관련된 쓰임새를 하나의 패키지로 그룹화 하는것. 시스템이 여러개의 서브 시스템으로 구성되어 있거나, 시스템에 대한 다양한 요구를 수집하기 위하여 사용자의 의견을 조사할 때 (즉, 요구사항이 각각의 쓰임새로 표현되기 때문에) 그룹화를 한다. 패키지 다이어그램에서 패키지 안에 관련되 쓰임새를 넣어서 표현


예) 가계부 시스템에서 통장 관리 관련된 쓰임새를 패키지로 그룹화 한것


[요구사항 수집]과 [분석] 영역에서의 USECASE 다이어그램


1. 의뢰인과의 인터뷰

2. 시스템 분야 (문제해결 대상이 되는 Domain)에 대한 기초가 되는 Class Diagram을 그림

3. 용어 정리후 사용자와의 인터뷰

4. 행위자의 추상적 수준의 USECASE 다이어그램을 그림으로써 기능적인 요구사항 정리

5. 사용자와의 계속적인 인터뷰를 통한 시스템 요구사항 구체화 → USECASE 모델은 상세한 자신의 시나리오를 가지게 되고, 포함관계 & 확장관계가 나타나게 됨.


* 그 분야에 대한 이해가 부족하게 되면 쓰임새가 쓸데없이 많아지게 되고 시스템 설계와 개발 작업에 오히려 발목을 잡히게 됨