소프트웨어 개발 단계를 다시 정리해보면 다음과 같다. specification - design - implementation - testing - maintanance 우리는 지금까지 요구사항을 정리하여 use case description 을 만드는 specification커뮤니케이션 다이어그램, 시퀀스 다이어그램, 클래스 다이어그램을 그리는 design, implementation 까지 모두 살펴보았다. 이제 마지막으로 testing 에 대해 정리해보자. Verification & Validation (V & V)중간고사 범위의 글에서 간략하게 정리했던 것처럼 testing 단계는 verification & validation 단계라고도 표현한다. verification (검증) 은 소프트웨어를 s..
디자인 패턴은 특정 상황에서 반복적으로 등장하는 문제에 대한 잘 알려진 솔루션이다.디자인 패턴은 말그대로 '패턴' 이기 때문에 이렇게 만들어야겠다 하고 만들어낸 것이 아니라 (not invented)사람들이 자주 사용하는 솔루션들을 발견하여 패턴으로 정리해낸 것이다. (discover) 그렇다고 아무 문제에서 누구나 쉽게 떠올릴 수 있는 솔루션들을 정리한 것은 아니다.디자인 패턴은 어려운 문제에 대해 기발하고 유용했던 솔루션들을 모아서 정리함으로써,비슷한 문제가 발생했을 때 동일한 솔루션을 재사용해서 효율적으로 문제를 풀어나가기 위한 방법이다. 디자인 패턴은 이름, 문제, 해결방법, 예시코드, 연관된 패턴 정보들로 구성되어있다.이름은 그 패턴의 이름만으로 이 패턴이 어떤 문제를 어떻게 해결하려고 하는지를..
지금까지 클래스 단위의 모듈화, 컴포넌트 단위의 모듈화 방법을 정리하였다.이제 단계를 높여서 서브 시스템 아키텍처를 설계해보자. 소프트웨어를 만들 때 requirement 를 모두 찾았다면 제일 먼저 아키텍처를 그려야 한다.'아키텍처' 라고 하면 big picture 를 생각하면 된다.그리고 제일 먼저 서브 시스템과 컴포넌트를 찾아서 이들 사이의 관계 (인터페이스) 를 정의해야 한다. 서브 시스템을 정의해보면 같은 특성을 공유하는 element 의 그룹으로 정의한다.예를 들어 UI 와 같이 사람과 컴퓨터 사이의 인터페이스 역할을 하는 element 를 모으면 'HCI 서브 시스템' 과 같이 분류할 수 있다. 이렇게 서브 시스템을 나누면 몇 가지 장점이 있다.'독립적인' 개발 단위 크기가 줄어들고 comp..
C 라는 절차지향 언어에서 C++ 이라는 객체지향 언어가 등장한 이유는 '모듈화' 때문이다.모듈화를 한다는 것은 소스코드의 각 조각을 독립적으로 만든다는 것이고,각 조각이 독립적이라는 것은 다른 소스코드에 의존하지 않는다는 것이다.또한 각 조각은 필요에 따라 얼마든지 쉽게 '재사용' 될 수 있다. 객체지향에서 소스코드를 재사용하기 위한 제일 핵심적인 개념은 '캡슐화(encapsulation)' 이다.필요한 행위만 외부에 보여주고 나머지 디테일한 구현은 다 숨기는 것이다. 캡슐화를 할 때는 2가지를 지켜야 한다.1. 외부에 보여질 인터페이스의 수 (public function) 를 최소화해야 한다.2. 인터페이스를 한번 정의할 때, 시간이 지나도 수정되지 않도록 잘 정의해야 한다. 지금까지는 캡슐화의 범위..
지금까지 requirement description 을 기반으로 커뮤니케이션 다이어그램 또는 시퀀스 다이어그램을 그린 뒤, 이 결과를 클래스 다이어그램으로 변환하는 모든 과정을 살펴보았다.이번 글에서는 사용자 UI 를 설계하는 과정을 더 자세히 정리한다. 우리는 시스템 아키텍처를 설계할 때 boundary class, control class, entity class 3가지 종류로 구분하여 설계하였다.이를 가리켜 3-tier architecture 라고도 부른다. boundary class 는 presentation layer 라고도 부르며,사용자 또는 다른 외부 시스템에서 사용하는 인터페이스를 다루고,사용자가 데이터를 입력할 수 있는 매커니즘을 제공하며,인터페이스에 가지고 있는 데이터를 적절하게 포맷팅..
지난 글에서는 커뮤니케이션 다이어그램 대신 그릴 수 있는 시퀀스 다이어그램에 대해 정리하였다.이번 글에서는 커뮤니케이션 다이어그램 / 시퀀스 다이어그램을 통해 그렸던 analysis class diagram 에 detailed design 을 추가하는 방법을 정리해본다. 클래스 다이어그램에 detailed design 을 추가하는 것은 다음 작업들을 하는 것이다. 1. 어트리뷰트 타입 추가클래스 다이어그램에 어트리뷰트를 기술할 때는 다음과 같이 기술한다. 이름 : 타입 = 초기값 {특성 값} 특성 값에는 constant, fixed, not null 과 같은 특성을 기술한다.이름 앞에 / 를 붙이면 상속받은 (derived) 특성을 나타내고, 밑줄을 그으면 class-scope(static) 변수를 나타..
지난 글에서는 use case description 으로부터 시스템을 설계하는 class diagram 을 만드는 과정을 정리하였다.이때 중간에 오브젝트 간 상호작용을 표현하는 방법으로서 communication diagram 으로 상호작용을 표현했다.이번 글에서는 sequence diagram 이라는 또 다른 오브젝트 간 상호작용 표현 방법을 정리해본다. Sequence Diagram시퀀스 다이어그램은 오브젝트간 상호작용을 시간순으로 나타낸 다이어그램이다.그리고 이 상호작용의 디테일 정도는 계층을 나눠서 필요한 만큼만 표현한다.한번에 모든 상호작용의 전체 디테일을 다 표현하면 너무 복잡하기 때문이다. 시퀀스 다이어그램은 클래스 다이어그램을 그리기 전 커뮤니케이션 다이어그램 대신에 그릴 수 있는 다이어그..
소프트웨어 개발의 주요 단계를 다시 정리해보면 다음의 5단계를 거쳐서 소프트웨어를 개발한다. 1. specification2. design3. implementation4. test5. maintenance specification 단계에서는 사용자의 요구사항을 파악하고, use case diagram 을 통해 시스템의 기능을 시각화하였다.그리고 사용자의 액션에 따라서 시스템이 어떻게 응답해야 하는지 use case description 을 작성하여 시스템에서 개발해야 하는 부분이 어디인지 명확하게 정의하였다. 이번 글부터는 design 단계를 진행한다.design 단계에서는 앞서 파악한 요구사항을 분석하여, 실제로 프로그램을 개발할 때 어떤 클래스와 메서드를 사용할 지 설계한다.이 과정을 마치고나면 커..
Configuration Management (CM)CM은 소프트웨어 시스템의 변화를 관리하는 도구, 프로세스, 정책과 관련된 개념이다.특히 팀 프로젝트를 하다보면 각 개발자들이 서로 다른 변화를 만들어내기 때문에 이 변화들을 관리하기 위해 필수적이다. 소프트웨어 컴포넌트의 확정된 변경사항은 버전별로 repository 라는 공동 저장소에 저장되어 있고, 개발자들은 repository 에 있는 코드를 자신의 workspace 로 가져와서 개발한다. CM 에서 수행하는 활동은 크게 4가지가 있다. 1. version management시스템 컴포넌트를 버전 별로 추적 관리하는 것 2. system building컴포넌트, 데이터, 라이브러리를 모아서 하나의 실행가능한 프로그램으로 만드는 것 3. chan..
