다양한 기록

개념 클래스 다이어그램 : 엔티티(수동적인 클래스)만 가짐분석 클래스 다이어그램 : 제어 + 경계 + 엔티티 클래스 다 가짐설계 클래스 다이어그램 : 클래스의 속성, 연산, 관계를 나타낸 세부적인 형태 분석 클래스 모델의 작성- 유스케이스 명세서를 바탕으로 분석 수준의 클래스 모델 작성- 비기능적 요구사항은 고려하지 않고 기능적 요구사항만 고려- 운영체제, 미들웨어, 프레임워크 등의 플랫폼을 고려하지 않음 분석 클래스들은 그 역할에 따라 분류경계 클래스 (boundary class)- 시스템과 외부 액터와의 상호작용을 전담하는 클래스- 시스템의 기능 중에서 입력과 출력만을 전담하는 클래스 제어 클래스 (control class)- 시스템이 실제로 제공하는 비즈니스 로직 및 제어 로직을 전담하는 클래스 엔..

연관 관계두 개 이상의 클래스 간 관련성을 뜻함메시지 전달의 통로 역할 .. 다른 객체에게 메시지를 전달함으로써 해당 객체의 기능 이용방향성 지정 가능 연관 관계의 다중성집합/포함 관계검은색 다이아: 포함흰색 다이아: 집합 - 집합 관계에서는 객체가 포함이 될 수도 있고 아닐 수도 있음- 포함 관계에서는 객체가 반드시 포함되어야 함- 집합 관계에서는 부분 객체가 다수의 전체 객체에 의해 공유- 포함 관계에서는 부분 객체가 오직 하나의 전체 객체에 소속- 반드시 has-a 관계 성립일반화 관계- 많은 클래스 간의 일반화 관계를 전체적으로 정의한 것을 일반화 계층 구조라 함- 하위 클래스가 상위 클래스의 모든 특성을 보유함- 물려받은 속성과 연산을 특별히 표시하지 않음- 추상 클래스는 객체를 생성할 수 없는..

분석 단계의 역할- 시스템의 구성 요소를 파악하는 것이 목표- 시스템의 구성 요소는 개발 방법론에 따라 달라질 수 있음개발 방법론시스템 구성 요소구조적 방법론모듈(함수, 프로시저)객체지향 방법론클래스컴포넌트 기반 방법론컴포넌트구조적 방법론- 모듈은 임베디드 소프트웨어 분야에서 사용되는 시스템 구성 요소객체지향 방법론- 클래스는 1990년대 이후 객체지향 방법론을 적용한 기본 요소컴포넌트 기반 방법론- 컴포넌트는 별도의 인터페이스에 의해서만 기능을 수행하는 소프트웨어 모듈 역할- 클래스 결정- 클래스 별 속성, 연산, 연관 관계 도출- 도출된 클래스는 완전하고 정확해야 함 구성 요소산출물관점설명UML분석 클래스 모델정적 관점클래스, 클래스 간의 관계클래스 다이어그램분석 유스케이스 실현 모델동적 관점객체들 ..

유스케이스 모델의 조직화- 많은 수의 액터와 유스케이스를 체계적으로 관리하고 유스케이스 다이어그렘으로 표현 필요- 수십개의 유스케이스를 하나의 유스케이스 다이어그램으로 표현하는 것은 비효율적=> 패키지를 사용하여 많은 수의 모델 요소를 체계적 관리 조직화된 유스케이스 모델- 구조화된 유스케이스 모델을 유사성에 따라 적절히 패키징- 조직화된 유스케이스 모델은 이후 개발 단계에서 프로젝트 관리 기준으로 사용- 하나의 유스케이스 패키지는 적절한 개수의 유스케이스를 포함하며 유사한 특성 표현- 유스케이스 모델의 크기, 유사성 등 고려 패키지는 다수의 모델 요소를 그룹화하는 수단- 폴더를 이용해 많은 파일을 관리하는 것과 동일- 동일한 이름을 가진 클래스가 서로 다른 패키지에 존재 가능 성격이 다른 유스케이스는 ..

유스케이스 모델의 구조화- 복잡도 측면에서 개선- 시스템의 기능적 요구사항은 그대로 유지 액터 일반화, 유스케이스 일반화, 유스케이스 포함, 유스케이스 확장  액터 일반화두 개 이상의 유사한 액터를 일반화 해 부모 액터 정의- 상위 클래스로 상속시키는 것과 유사- 일반화는 클래스 사이의 일반화와 동일한 표기법 사용- 일반적인 액터를 부모 액터, 구체적인 액터를 자식 액터- 부모 액터처럼 실제 객체로서 존재하지 않는 액터를 추상 액터라 하고 유스케이스 다이어그램에서 이탤릭체로 표기- 모든 자식 액터는 부모 액터와 동일한 상호 작용을 함  유스케이스 일반화두개 이상의 유사한 유스케이스를 일반화- 유스케이스 일반화를 통해 부모 유스케이스 정의- 부모 유스케이스는 액터에 의해 동작되지 않는 추상 유스케이스- 이..

유스케이스 다이어그램에 기술된 각 유스케이스를 구체적으로 기술Usecase => Usecase 명세서 유스케이스 명세서유스케이스에 대한, 보다 구체적인 명세- 유스케이스 이름 : 유스케이스에 대한 가장 간결한 명세로서 유스케이스를 통하여 제공되는 시스템의 기능을 명확한 동사 구 형태로 표현- 개요 : 모든 이해 관계자는 가장 먼저 유스케이스 명세서의 개요 항목을 통해서 유스케이스 이해- 관련 액터 항목 : 해당 유스케이스가 동작할 때 필요한 주변 액터 이해 가능, 주액터와 보조액터를 구분하여 기록- 우선 순위 : 기능의 중요도와 개발 난이도를 바탕으로 결정, 개발 순서, 자원 투입 증과 같이 프로젝트 관리 측면에서 사용- 선행 조건 : 유스케이스의 시작 시 만족되어야 할 조건으로서 만족되지 않으면 유스케..

유스케이스 모델의 작성- 목표: 사용자의 요구사항을 누락 없이 도출- 액터와 유스케이스 간의 연관 관계를 다이어그램으로 표현- 유스케이스 모델은 시스템의 요구사항을 빠짐없이 기술- 핵심 기능은 반드시 유스케이스로 도출 유스케이스 모델- 액터- 유스케이스액터- 시스템과 상호작용하는 시스템 외부의 존재 .. 시스템에 입력을 주는 존재와 시스템에게서 결과를 받는 존재- 개발 대상이 되는 시스템에 따라 달라짐- 일반적으로 사용자, 외부 시스템, 장치의 세가지로 분류 유스케이스- 개발 대상이 되는 시스템이 제공하는 개별적 기능- 유스케이스로 표현된 기능은 시스템 사용자가 이용- 유스케이스의 기능과 이를 이용하는 액터와의 관계 표현- 기능적 요구사항은 요구사항은 유스케이스로 구성액터- 시스템 외부의 존재- 장치 유..

요구사항 정의의 역할- 사용자들의 요구를 명세, 검증, 확인하는 활동- 소프트웨어가 제공하는 특성으로 명확한 기준 정립- Stakeholders (이해 당사자) 분류요구사항- 기능정 요구사항- 비기능적 요구사항    - 품질 요구사항    - 제약사항 유형기능적 요구사항- 사용자가 직접 이용하는 개별적인 기능에 대한 정의- 시스템에 주어지는 특정 입력에 시스템이 산출하는 출력에 의해 정의식별자입력출력Req-1사용자가 휴대폰의 통화 버튼을 누른다시스템은 최근 통화 목록을 표시한다.첫 항목을 선택시킨다.Req-2사용자가 한 번 더 통화 버튼을 누른다.시스템은 선택된 항목의 전화 번호로 통화를 시도한다. 통화 연결음을 들려준다.Req-3사용자가 통화 중에 종료버튼을 누른다.시스템은 연결을 종료시킨다.Req-4..