프로젝트 기획 및 설계
1. 소프트웨어 공학(Software Engineering)
1.1 소프트웨어의 개발, 운용, 유지보수 등의 생명 주기 전반을
체계적이고 서술적이며 정량적으로 다루는 학문
1.2 즉, 공학을 소프트웨어에 적용하는 것
2. 정보시스템 개발 프로세스
구글 검색
폭포수 모델(Waterfall Model) :
요구사항 정의 및 분석, 시스템 설계, 구현, 테스팅이라는 일련의 단계를 통해 소프트웨어(시스템)를 개발하는 모델
애자일 모델(Agile Model)
3. 요구공학(Requirements Engineering) : 요구사항을 정의하고 문서화하고 관리하는 프로세스
3.1 현행 시스템 분석하기
3.1.1 현행 시스템 파악
- 현행 시스템 파악 : 현행 시스템의 하위 시스템, 제공하는 기능, 기술요소, 사용하는 소프트웨어 및 하드웨어, 네트워크 구성 정보 등을 파악
- 현행 시스템 파악의 목적 : 향후 개발하고자 하는 시스템의 개발범위 및 방향성 설정
- 현행 시스템 파악 절차 (3단계)
- 정보시스템 구성 현황 작성 예시
- 시스템별 소프트웨어 현황 작성 예시
- 시스템별 하드웨어 현황 작성 예시
3.1.2 개발 기술 환경 정의
- 개발 기술 환경 정의시 고려사항
OLTP(OnLine Transaction Processing, 온라인 트랜잭션 처리)
- 운영체제의 종류 및 특징
일반적으로 리눅스(Linux) 기반 시스템이 하드웨어 및 소프트웨어 비용이 가장 적게 소요된다.
유지 및 관리 비용 측면에서는 윈도우즈(Windows) 기반 시스템이 강점을 가진다.
안정적이고 신뢰할 수 있으며 대용량 처리를 위해서는 유닉스 기반 시스템이 선호되고 있다.
- DBMS 종류 및 특징
3.2 요구사항 확인
3.2.1 요구사항 도출
- 요구사항이 어디에 있고 어떻게 수집할 것인가와 관련
- 이해관계자(Stakeholder)가 식별되고 개발 팀과 고객 사이의 관계가 만들어진다.
- 다양한 이해관계자와 효율적인 의사소통이 중요
3.2.2 요구사항 분석
- 요구사항들 간 상충되는 것을 해결하고, 소프트웨어의 범위를 파악하며, 소프트웨어가 환경과 어떻게 상호 작용하는지 이해한다.
3.2.3 요구사항 명세
- 요구사항 명세란 체계적으로 검토, 평가, 승인될 수 있는 문서를 작성하는 것을 의미한다.
- 시스템 정의, 시스템 요구사항, 소프트웨어 요구사항을 작성한다.
3.2.4 요구사항 확인
- 분석가가 요구사항을 이해했는지 확인(Validation)하고, 요구사항 문서가 회사의 표준에 적합하고 이해 가능하며, 일관성이 있고, 완전한지 검증(Verification)
3.2.5 개념 모델링(Conceptual Modeling)
- 실세계 문제에 대한 모델링이 소프트웨어 요구사항 분석의 핵심
- 개념 모델은 문제가 발생하는 상황에 대한 이해를 증진시키고 해결책을 설명한다.
- 개념 모델의 종류와 표기법
1) 대부분의 모델링 표기법은 UML(Unified Modeling Language)을 사용한다.
2) 유스케이스 다이어그램(Use Case Diagram), 데이터 흐름 모델(Data Flow Model), 상태 모델(State Model), 목표기반 모델(Goal-Based Model), 사용자 인터액션(User Interactions), 객체 모델(Object Model), 데이터 모델(Data Model) 등과 같은 다양한 모델을 작성할 수 있다.
3.2.6 요구사항 목록 예시
3.2.7 요구사항의 시스템화 타당성 분석
- 요구사항의 기술적 타당성 검토 4단계
- 요구사항의 시스템화 타당성 분석 결과 예시
3.3 분석모델 확인하기
3.3.1 유스케이스 모델 검증
3.3.2 분석 클래스의 스테레오 타입
3.3.3 유스케이스 다이어그램 예시
3.3.4 유스케이스 모델 검토 의견 작성 예시
3.3.5 분석 클래스 모델 검토 의견 작성 예시
3.3.6 분석 클래스 모델의 기술적 타당성 검토 예시
4. UML
4.1 UML이란?
Unified Modeling Language, 통합 모델링 언어
4.1.1 소프트웨어 공학에서 사용되는 표준화된 범용 모델링 언어
4.1.2 소프트웨어의 시각적 모델을 만들기 위해 사용하는 시각적인 표기법
4.1.3 객체 지향 소프트웨어 집약 시스템을 개발할 때 산출물을 명세화, 시각화, 문서화할 때 사용
4.2 주요 UML 다이어그램
4.2.1 클래스 다이어그램
4.2.2 시퀸스 다이어그램
5. 유스케이스(Use-cases)
5.1 유스케이스란
- 쓰임새, 용도의 의미
- 어떤 시스템을 만드느냐를 사용자 입장에서 바라보는 것
- 시스템의 기능을 정의하고 범위를 결정함으로써 시스템과 외부 환경 변수를 구분하고 상호 관계를 정립하는 것
5.2 유스케이스 다이어그램
- 시스템과 액터(Actor)와의 의사소통을 표현
- 액터(Actor, 행위자)
- 유스케이스(Use-cases) : 타원으로 표현, 사용자의 관점에서 보는 행위
- 관계(Relationship) : 선으로 표현하며 관계의 방향성은 화살표로 표현
5.2.1 Actor의 Generalization(일반화, 상속)
운용자는 사용자를 Generalization(상속)한다. 즉, 일반 사용자가 할 수 있는 일은 운영자도 할 수 있다.
사용자는 로그인을 할 수 있고 운영자도 로그인을 할 수 있다.
운영자는 로그인과 권한 설정을 할 수 있다. 하지만 일반 사용자는 로그인만 할 수 있고 권한 설정은 할 수 없다.
5.2.2 유스케이스의 include
- 필수적, 공통으로 사용되는 유스케이스나 사용자의 요구로 인해 분리시켜야 할 유스케이스에 사용
- 하위 직업의 관계를 표시할 때 사용
고객이 로그인시에 SSO(Single Sign On, 단일 로그인)을 요구할 경우
손님은 계산을 할 때 현금결제, 카드결제, 외상 등의 방법을 사용할 수 있다.
5.2.3 시스템 경계
- 시스템을 구분하기 위해 표시하는 사각형의 구역
- 시스템 내부는 사각형 안에 표시하고 외부는 사각형 바깥에 표시
5.2.4 유스케이스의 사용 예
6. 유스케이스 작성 도구
https://sourceforge.net/projects/staruml 오픈소스(무료)
http://staruml.io 유료
* 유스케이스 다이어그램 작성 예
7. 클래스 다이어그램(class diagram)
- 시스템의 정적인 상태인 논리적인 구조(클래스)를 표현
- class, interface 간의 관계를 나타내며 객체지향 개발에서 많이 사용됨
- 접근제한자
- 클래스 표기법
- 의존관계(Dependency) : 한 객체가 다른 객체를 소유하지는 않지만 다른 객체의 변경에 따라서 같이 변경을 해주어야 하는 관계
- 연관관계(Association) : 한 객체가 다른 객체를 소유(사용)하거나 참조하는 경우
- 일반화(Generalization) : 상속 관계를 의미함(is a 관계)
* 이클립스 플러그인 설치(http://www.objectaid.com)
Name: ObjectAid UML Explorer
URL: http://www.objectaid.com/update
8. 데이터베이스 설계(ERD)
8.1 개체-관계 모델링(Entity-Relationship Modelling) : 구조화된 데이터에 대한 일련의 표현
8.2 개체-관계 다이어그램(Entity-Relationship Diagram) : ERM 프로세스의 산출물
8.3 ERD 작성툴
- ER Win
- PowerDesigner
- Rational Rose
- eXERD 등
8.4 toad에서의 ERD 생성
- Database - Report - ER Diagram 실행
- View - Object Palette를 선택하면 테이블 목록을 확인할 수 있음
8.5 eXERD에서의 작성 예
- http://ko.exerd.com 에서 프로그램 다운로드 및 설치