다양한 기록

1. Code-and-Fix Model- 디자인, 사양 없고 유지보수에 고생- 개발하긴 쉬운데 가장 돈이 많이 들게 됨2. Waterfall Model (리니어 모델)요구사항 정의 - 분석 - 설계 - 구현 - 유지보수 ..다음 단계로 넘어가면 이전 단계로 돌아가기 어려움- 요구 사항이 명확한 경우 유용- 현실은 더 복잡하고 요구사항은 바뀜- 소비자는 코드가 준비될 때까지 마냥 기다려야 함- 커스터머로의 피드백 부족은 실수가 재앙이 됨3. Prototype ModelSW는 사람이 하는 일 +@를 함 .. 고객이 제대로 표현하기가 힘듦요구사항을 그냥 얻어내기는 힘드니까 일단 프로토타입을 만들고 요구사항을 확실히 얻어내는 방식 => 시제품"Quick and dirty"a) Throw-away(Rapid) p..

의미- 주어진 목적을 위해 수행되는 일련의 절차역할- 절차, 인력, 기술을 통합- 각 순서와 활동이 명확하게 정의* 조직원들의 행동 양식을 지정해주는 역할Definition of Process- 소프트웨어 제품을 생산하기 위해 적용되는 과정과 활동, 그리고 산출물들 Five Basic Steps of SW Process- Analysis : 시스템이 무엇을 해야 하는지 정의- Design : 시스템 구조를 정의- Implmentation : 시스템 구현- Validation : 소비자가 원하는 것인지 체크- Maintanence : 고객 니즈 변화에 따른 시스템 변화 Process may include:ProductsRolesPre- and post- conditionsPlan-driven and Agi..

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

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

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

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