● 소프트웨어 설계 시 성능 측정 주요 지표
| 응답 시간 (Resoponse Time) |
사용자 측면에서 응답시간이 성능 목표 기준. 응답시간은 업무 처리에 소요되는 시간 | ||||
| 업무량/처리량 (Through put) |
업무 피크 시간 동안에 시스템이 처리해야 하는 단위 시간당 최대 업무 처리 건수 | ||||
| 가용성 (Availability) | 시스템이 정상적으로 사용 가능한 시간 | ||||
| 사용률 (Utilization) | CPU, 메모리, 디스크, 네트워크 등의 사용 비율 | ||||
● 플랫폼의 개념
- 응용 소프트웨어 개발의 생산성 향상에 많은 도움을 준다.
- 응용 소프트웨어의 가동을 위해 하드웨어, 소프트웨어, 네트워크 등 다양한 주변기기 등이 결합한 형태이다.
- 이미 제작한 소프트웨어에 대해 언제, 어디서나 실행시키더라도 쉽게 구동시킬 수 있다.
- 장점으로는 개발과 운영을 쉽게 하며 비용 감소 효과가 있다.
● 현행 시스템 파악 3단계
1단계 : 구성/기능 및 인터페이스 파악
- 현행 시스템의 핵심 및 지원 업무의 구성
- 단위 업무 시스템이 제공하는 기능
- 단위 업무 시스템이 다른 단위 업무 시스템과 주고받는 데이터
2단계 : 아키텍처 및 소프트웨어 구성 파악
- 핵심 업무 수행을 위해 사용되는 시스템 아키텍처 구성도
- 단위 업무 처리에 필요한 소프트웨어들의 상세 정보
3단계 : 하드웨어 및 네트워크 구성 파악
- 단위 업무의 하드웨어 주요 사양, 수량, 운용 형태 등 업무 처리 시스템의 네트워크 연결 방식, 물리적 관계, 보안성
● 애플리케이션 소프트웨어의 주요 연계 프로토콜 기술
| X.25 | DTE(데이터 터미널 장치)와 DCE(데이터 회선 종단장치)간 인터페이스를 제공하는 프로토콜 두 단말장치가 패킷 교환망을 통해 패킷을 원활히 전달 |
| Open API | 애플리케이션 소프트웨어를 구축하고 통합을 위해 정의된 프로토콜 세트 공개된 애플리케이션 프로그래밍 인터페이스를 의미 |
| Json | 속성-값 쌍 또는 키-값 쌍으로 이루어진 데이터 오브젝트를 전달하기 위해 사람이 읽을 수 있는 텍스트를 사용하는 개방형 표준 포맷 |
| DB Link | 데이터를 연계하려는 DB 시스템 간 직접 연결을 통해 데이터를 연계 |
● 현행시스템 파악 활동
| 현행시스템 기능 | 단위 업무 시스템이 현재 제공하고 있는 기능을 기술 |
| 현행시스템 구성 현황 | 조직의 주요 업무를 처리하는 기간 업무와 이를 지원하는 지원 업무로 구분하여 기술 |
| 인터페이스 현황 | 단위 업무 시스템이 다른 단위 업무 시스템과 주고받는 데이터의 종류, 데이터 형식, 프로토콜, 연계유형, 주기 등을 명시 |
| 현행시스템 아키텍처 구성도 | 조직의 업무를 수행하기 위하여 계층별로 어떠한 기술 요소들을 사용하고 있는지 최상위 수준에서 그림으로 표현 |
| 소프트웨어 구성도 | 단위 업무 시스템의 업무 처리를 위해 설치되어 있는 소프트웨어들의 제품명, 용도, 라이센스 적용 방식, 라이센스 수를 명시 |
● Json의 주요 형식
- Json 데이터는 이름과 값의 쌍으로 이루어짐.
- Json 데이터는 쉼표(,)로 나열됨.
- 객체(object)는 중괄호({ })로 표현.
- 배열(array)은 대괄호([ ])로 표현.
● OSI 7 Layer
| 계층 | 설명 | 주요 프로토콜 | 단위 |
| 응용 계층 (Application Layer) |
사용자와 네트워크 간의 응용 서비스 연결, 데이터 생성 | HTTP, TELNET, DHCP, DNS, FTP, SSH, SMTP, SNMP | Data |
| 표현 계층 (Presentation Layer) |
데이터의 형식 설정과 부호 교환, 암호화, 해독 | MIME, TLS, SSL, JPEG, MPEG, SMB, AFP | Data |
| 세션 계층 (Session Layer) |
응용 프로세스 간의 연결 접속 및 동기 제어 | SSH, TLS, RPC | Data |
| 전송 계층 (Transport Layer) |
프로세스 간 논리적 통신 서비스 제공. 패킷들의 전송유효 확인, 실패한 패킷은 재전송하여 신뢰성 있는 통신 보장 | TCP(3-Way Handshaking), UDP, SCTP, RTP | Segment |
| 네트워크 계층 (Network Layer) |
단말 간 시스템끼리 데이터를 전송하기 위한 최선의 통신경로 선택을 제공 | IP, ARP, ICMP, IGMP, IPsec | Packet |
| 데이터링크 계층 (Data Link Layer) |
인접 시스템 간의 데이터 전송, 전송 오류 제어. 오류검출/재전송/흐름제어 | Ethernet, ATM, PPP | Frame |
| 물리 계층 (Physical Layer) |
통신회선으로 데이터를 나타내는 '0'과 '1'비트의 정보를 회선에 내보내기 위한 전기적 변환이나 기계적 작업을 담당 | RS-485, RS-232, X25/21 | Bit |
● DBMS의 주요 기능
| 명령어 종류 | 명령어 | 설명 |
| 데이터 정의어(DDL) | CREATE, ALTER, DROP, RENAME | 테이블과 같은 데이터 구조 정의에 사용되는 명령어 구조의 생성, 변경, 삭제 및 이름 변경과 관련된 명령어 |
| 데이터 제어어(DCL) | GRANT, REVOKE | DB에 접근하고 객체들을 사용하도록 하는 권한 부여 또는 권한 회수와 관련된 명령어 |
| 데이터 조작어(DML) | SELECT | DB에 저장된 데이터를 조회하기 위한 명령어 |
| INSERT, UPDATE, DELETE | DB 테이블의 데이터에 변경을 가하는 종류의 명령어 새로운 데이터를 추가하거나 기존 데이터의 변경 및 삭제를 하는 명령어 |
|
| 트랜잭션 제어어(TCL) | COMMIT, ROLLBACK | DML에 의해 조작된 결과를 작업 단위 별로 제어하는 명령어 TCL은 DCL로 포함시키기도 함 |
● 현행 시스템 분석 수행 활동
- DBMS 분석 : 데이터베이스 생성, 조회, 변경 등의 관리 사항을 분석
- 네트워크 분석 : 네트워크 상호 연결 구조, 프로토콜, 통신 용량, 성능 분석
- 운영체제 분석 : 정보시스템 구축 시 운영체제 관련 요구사항을 분석
● 다중 프로그래밍 시스템에서 발생하는 교착상태(Deadlock)의 4가지 필요조건
- 상호 배제 (Mutual Exclusive) : 프로세스가 자원을 배타적으로 점유하여 다른 프로세스가 그 자원을 사용할 수 없음.
- 점유와 대기 (Block & Wait) : 한 프로세스가 자원을 점유하고 있으면서 또 다른 자원을 요청하여 대기하고 있는 상태
- 비선점 (Non Preemption) : 한 프로세스가 점유한 자원에 대해 다른 프로세스가 선점할 수 없고, 오직 점유한 프로세스만 해제 가능.
- 환형 대기 (Circular wait) : 두 개 이상의 프로세스간 자원의 점유와 대기가 하나의 원형을 구성한 상태
● 트랜잭션의 성질
트랜잭션 = 데이터베이스의 상태를 변화시키는 하나의 논리적 기능을 수행하기 위한 작업의 단위 또는 한꺼번에 모두 수행되어야 할 일련의 연산들을 의미함.
- Atomicity (원자성) : 트랜잭션의 연산은 데이터베이스에 모두 반영되던지 아니면 전혀 반영되지 않아야 한다는 성질. 트랜잭션 내의 모든 명령은 반드시 완벽히 수행되어야 하며, 모두가 완벽히 수행되지 않고 어느 하나라도 오류가 발생하면 트랜잭션 전부가 취소되어야 함.
- Consistency (일관성) : 트랜잭션이 그 실행을 성공적으로 완료하면 언제나 일관성있는 데이터베이스 상태로 변환한다는 성질. 시스템이 가지고있는 고정요소는 트랜잭션 수행 전과 수행 후의 상태가 같아야 함.
- Isolation (독립성, 격리성) : 둘 이상의 트랜잭션이 동시에 병행 실행되는 경우 어느 하나의 트랜잭션 실행 중에 다른 트랜잭션의 연산은 진행되지 않음. 수행중인 트랜잭션은 완전히 완료될 때까지 다른 트랜잭션에서 수행 결과를 참조할 수 없게 되는 것.
- Durability (지속성, 영속성) : 성공적으로 완료된 트랜잭션의 결과는 시스템이 고장 나더라도 영구적으로 반영되어야 한다는 성질.
● 스키마(Schema)
스키마 = 데이터 베이스의 구조와 제약 조건에 관한 전반적인 명세를 기술한 메타데이터의 집합.
스키마는 DB를 구성하는 Entity, Attribute, Relationship 및 데이터 값들이 갖는 제약 조건 등에 관해 전반적으로 정의함.
3가지 관점의 스키마 :
| 외부 스키마 (= 사용자 뷰) |
사용자나 응용프로그래머가 각 개인의 입장에서 필요로 하는 데이터베이스의 논리적 구조를 정의한 것. 외부스키마는 전체 DB의 한 논리적인 부분으로 볼 수 있으므로 서브스키마라고도 함. 하나의 DB 시스템에는 여러개의 외부 스키마가 존재할 수 있으며 하나의 외부 스키마를 여러개의 응용 프로그램이나 사용자가 공용할 수 있음. 같은 데이터 베이스에 대해서도 서로 다른 관점을 정의할 수 있도록 허용함. 일반 사용자는 질의어(SQL)를 사용하여 DB를 사용할 수 있음. 응용 프로그래머는 C, JAVA 등의 언어를 사용하여 DB에 접근. |
| 개념 스키마 (= 전체적인 뷰) |
개념 스키마는 DB의 전체적인 논리적 구조로서, 모든 응용 프로그램이나 사용자들이 필요로 하는 데이터를 종합한 조직 전체의 데이터베이스로 하나만 존재함. 개념 스키마는 개체간의 관계와 제약 조건을 나타내고 데이터베이스의 접근 권한, 보안 및 무결성 규칙에 관한 명세를 정의함. DB 파일에 저장되는 데이터의 형태를 나타내는 것으로, 단순히 스키마라고 하면 개념 스키마를 의미함. 기관이나 조직체의 관점에서 DB를 정의한 것임. 데이터베이스 관리자에 의해서 구성됨. |
| 내부 스키마 (= 저장 스키마) |
내부 스키마는 물리적 저장장치 관점의 데이터베이스 구조임. 내부 스키마는 실제로 DB에 저장될 레코드의 물리적인 구조를 정의하고, 저장 데이터 항목의 표현방법, 내부 레코드의 물리적 순서 등을 나타냄. 시스템 프로그래머나 시스템 설계자가 보는 관점의 스키마. |
● 요구사항 개발 프로세스 순서
도출 → 분석 → 명세 → 확인
| 도출 | 분석 | 명세 | 확인 |
| 요구사항 원천 도출기법 | 요구사항 분류 개념 모델링 기술구조 설계, 요구사항 할당 요구사항 협상 |
시스템 정의서 시스템 요구사항 명세서 소프트웨어 요구사항 명세서 |
검토 프로토타이핑 모델 검증 인수 테스트 |
● 유스케이스 명세서 이벤트 흐름
- 기본 흐름 : 유스케이스의 기본적이고 정상적인 이벤트의 흐름. 그러나 흐름의 가변성에 의해 다양한 예외가 발생함에 따라 대체 및 예외가 필요하게 됨.
- 대체 흐름 : 조건에 따라 수행해야 하는 작업이 복잡한 경우 대체흐름으로 정리함.
- 예외 흐름 : 이벤트 흐름 중 예외가 발생하여 기본 흐름을 종료하는 경우 예외 흐름을 정리함.
● 코드화 기능
- 표준화 : 코드 대상이 되는데 데이터를 표준화하는 기능
- 간소화 : 데이터를 코드화함으로써 짧고 간결하고 명료화하는 것.
- 식별 : 각각의 데이터를 상대에 따라 구별하는 기능으로 식별 기능을 유지하기 위해서는 1개의 코드와 1개의 데이터가 1대 1로 대응해야 함.
- 분류 : 코드 대상이 되는 동일 특성을 가진 데이터를 그룹화 하는 기능
- 배열 : 데이터를 나열하는 것을 어떤 의미를 주어 결정하는 기능
- 연상 : 코드에 대한 해독을 쉽게하는 것으로 코드를 보는 순간 그 코드의 대상을 연상할 수 있도록 하는 기능
- 암호화 : 데이터를 코드화 함으로써 그 대상이 무엇인지 알지 못하게 하는 기능.
- 오류 검출 : 코드 자체에서 오류를 찾게 하는 기능.
종류 : Significant Digit Code, Block Code, Sequence Code, Decimal Code, Group Classification Code, Block Sequence Code, Final Digit Code, Mnemonic Code, Combined Code
● UML 활동 다이어그램의 3가지 노드
- 행위 노드 (Activity 안에서 최소한의 작업단위를 표현하는 모델 요소)
| 행위 호출 (Call Action) | 활동, 동작, 오퍼레이션을 호출 |
| 신호 송신 (Send Signal) | 신호 행위를 비동기적으로 송신 |
| 이벤트 수신 (Accept Event) | 이벤트 행위를 기다리고 수신 |
| 시간 이벤트 수신 (Accept Time Event) | 시간 이벤트 행위를 기다리고 수신 |
- 제어 노드 (Activity 흐름을 제어하는 모델 요소
| 초기 (Initial) | 활동을 시작하는 노드 |
| 활동 최종 (Activity Final) | 모든 플로우 활동을 종료하는 노드 |
| 플로우 최종 (Flow Final) | 해당 플로우를 종료하는 노드 |
| 결정 (Decision) | 하나의 입력 플로우와 여러 출력 플로우를 갖는 노드 |
| 병합 (Merge) | 여러 입력 플로우를 병합하여 하나의 플로우로 출력 |
| 분기 실행 (Fork) | 하나의 입력 플로우를 동시에 여러 출력 플로우로 분기하여 실행 |
| 결합 (Join) | 여러 입력 플로우를 동기화하여 하나의 플로우로 출력 |
- 객체 노드 (Activity 안에서 사용되는 객체를 표현)
| 객체 (Object) | 활동 다이어그램에 참여하는 일반적인 데이터 표현 |
| 입력 핀 (Input Pin) | 행위와 활동이 데이터를 받는 위치 |
| 출력 핀 (Output Pin) | 행위와 활동에 데이터를 보내는 위치 |
| 활동 매개변수 (Activity Parameter) | 활동으로 들어오고 나가는 데이터 매개변수 |
| 중앙 버퍼 (Central Buffer) | 여러 소스 및 대상으로부터의 데이터 플로우 관리 노드 |
| 데이터 스토어 (Data Store) | 데이터를 저장하고 추출하는 데이터 저장소 |
● 소프트웨어의 상위 설계와 하위 설계
- 상위 설계 (High Level Design) : 아키텍처 설계, 예비 설계라고 하며 시스템 수준에서의 소프트웨어 구성 컴포넌트들 간의 관계로 구성된 시스템의 전체적인 구조와 시스템 구조도, 외부 파일 및 DB 설계도, 화면 및 출력물 레이아웃 등이 포함됨.
- 하위 설계 (Low Level Design) : 모듈 설계, 상세 설계라고 하며, 시스템의 각 구성 요소들의 내부 구조, 동적 행위 등을 결정하며 각 구성 요소의 제어와 데이터들 간의 연결에 대한 구체적인 정의를 하는 것.
상위 설계에서는 개념적이고, 정적인 모델링에 집중하며 하위 설계는 상세하게 표현하고 동적인 모델링에 집중함.
● XP(eXtreme Programming)의 12가지 실천사항
| 1. Planning game (= Planning process) | 사용자 스토리를 이용해서 다음 릴리즈의 범위를 빠르게 결정. 비즈니스 우선순위와 기술적 평가가 결합 |
| 2. Small/Short releases | 필요한 기능들만 갖춘 간단한 시스템을 빠르게 릴리즈 고객이 소프트웨어가 어떻게 돌아가는지 아주 짧은 사이클(2주)로 볼 수 있도록 자주 새로운 버전 배포 유지 |
| 3. Metaphor | 공통의 name system 전체 개발 프로세스에 걸쳐서 시스템의 동작에 대한 전체 그림을 표현하는 것으로, 이해하기 쉬운 스토리로 이루어짐 |
| 4. Simple design | 당장 필요하지 않은 디자인 배제 항상 가능한 가장 간결한 디자인 상태 유지 |
| 5. TDD(Test Driven Development) | 개발자 먼저 단위 테스트, 실제 코드를 작성하기 전에 먼저 작성함으로써 자신이 무엇을 해야 하는지 스스로 깨우침 고객은 기능 테스트를 작성하여 요구사항이 모두 반영되었는지를 확인 |
| 6. Refactoring (Design Improvement) | 프로그램 기능은 변경 없이 중복/복잡성 제거, 커뮤니케이션 향상, 단순화, 유연성 추가 등을 통해 시스템 재구성 |
| 7. Pair programming | 두 사람이 함께 프로그래밍 모든 프로그래밍은 하나의 컴퓨터에 2명의 프로그래머가 같이 공동작업 진행 |
| 8. Collective Code Ownership | 팀의 모든 프로그래머가 소스코드에 대해서 공동 책임을 지는 것으로, 시스템에 있는 코드는 누구든지 언제라도 수정 가능함 |
| 9. CI (Continuous Integration) | 컴포넌트 단위로 혹은 모듈 단위로 나누어서 개발된 소스코드들은 하나의 작업이 끝날 때 마다 지속적으로 통합되고 동시에 테스트된다. |
| 10. 40-hour week (Sustainable Pace) | 일주일에 40시간 이상을 일하지 말도록 규칙으로 정하고 2주를 연속으로 오버타임 하지 않도록 함 |
| 11. Whole Team | 개발 효율성을 위해 고객을 프로젝트에 상주시킴. 고객은 스토리를 명확하게 해주고, 중요한 비즈니스 결정사항에 대해 명확한 답을 제공해 주는 역할 |
| 12. Coding Standard | 팀원들 간 커뮤니케이션을 향상시키기 위해서는 코드가 표준화된 관례에 따라 작성되어야 함. |
● DBC(Design By Contract)의 세가지 유형
| 선행 조건 (Precondition) | 루틴(함수/메서드/모듈)이 호출되기 위해 참이어야 하는 것 루틴의 선행조건이 위반된 경우 루틴이 호출되어서는 안 됨 제대로 된 데이터를 전달하는 것은 호출 쪽의 책임 |
| 후행 조건 (Postcondition) | 루틴이 자기가 할 것이라고 보장하는 것 루틴이 수행된 후 만족하여야 하는 조건 |
| 클래스 불변식 (Class invariant) | 호출자의 입장에서 볼 때는 이 조건이 언제나 참이라고 클래스가 보장 루틴의 내부 처리 중에는 불변식이 참이 아닐 수도 있지만, 루틴이 종료하고 호출자로 제어권이 반환되는 때에는 불변식이 참이 되어야 함 |
● 요구사항 도출 기법
| 문헌조사 | 유사 프로젝트 및 업무 문서나 양식을 조사하여 현재 시스템 정보에 대한 이해 도출. 그 외 산업 및 기업 표준, 관련 정부 정책, 규제 등 문서 조사 개발팀은 도메인 영역 교육이나 설명서 참고 |
| 업무절차 및 양식조사 | 업무 관련 문서, 절차, 양식, 운영 매뉴얼 등을 조사함으로써 업무절차와 처리 입출력의 이해 기업의 내부 표준을 검토함으로써 요구와 제한 사항을 찾아 시스템 요구 분석서의 제한 사항으로 적용 |
| 설문 | 이해당사자들로부터 요구를 찾는 도구 이해당사자들을 의사결정 과정에 포함하여 관심, 내부 정보, 개선 의견을 이끌어 냄 |
| 브레인스토밍 회의 | 여러 명으로부터 정보를 얻는 효과적 방법 인터뷰와 같이 수행하면 더 많은 정보 추출이 가능하며 훈련된 요원의 주재로 과정을 정돈하는 것이 성공의 키 포인트 JAD(Joint Application Development) : 사용자와 개발자가 공동 참여하여 프로토타입 기반의 작업을 수행함으로써 비즈니스 요구사항을 명확히 도출하고 그에 따라 시스템을 설계 및 개발 |
| 고객 발표 | 요구사항 도출을 시작하는 방법으로 개발팀에 고객의 업무를 소개하고 의심되는 부분을 명확화 하도록 질문 가능 구축하는 시스템의 초기에 개념 수립 가능 개발 대상 시스템에 대해 원하는 내용을 잘 알고 있는 사람(고객, 사용자)이 발표함으로써 관련 내용을 명확히 함. |
| 인터뷰 | 고객, 사용자, 도메인 전문가로부터 요구 정보를 효과적으로 수집 많은 정보 획득을 위한 계획이 중요하며 가능하면 많은 관련자들과 인터뷰, 관련자 외 사람들과도 인터뷰 고려 |
| 프로토타이핑 | 최종 시스템의 예상 기능 중 일부를 빠르게 구현한 프로그램으로 소프트웨어 엔지니어의 아이디어에 대한 피드백을 조기에 받아서 요구사항을 취합하는 것 주로 사용자 인터페이스를 종이에 그린 프로토타입이나 프로토타이핑 전용 언어로 모의 사용자(mock-up) 인터페이스를 만들어 사용 |
| 사용자 스토리 | 애자일 방법에서 요구 취합을 위하여 많이 사용하는 방법 사용자가 개발팀과 함께 만들고 시스템에 바라는 역량을 간단히 기술한 문서 |
● HIPO(Hierarchy Input Process Output)
HIPO = 하향식 개발을 위한 시스템 분석 및 설계 문서화 도구.
- 시스템을 표현하는 모듈들을 계층적으로 나타내고 각 모듈들을 문서화하기 위해 사용
- InputㅡProcessㅡOutput으로 이루어진 모듈을 계층적으로 나타낸 도표
도표 유형 :
| 가시적 도표 (Visual Table of Contents) |
시스템의 전체적인 기능과 흐름을 보여주는 Tree 형태의 구조도 |
| 총체적 도표 (Overview Diagram) |
프로그램을 구성하는 기능을 기술한 것으로 입력, 처리, 출력에 대한 전반적인 정보를 제공하는 도표 |
| 세부적 도표 (Detail Diagram) |
총체적 도표에 표시된 기능을 구성하는 기본 요소들을 상세히 기술하는 도표 |
● 요구사항 분석
요구사항 분석은 소프트웨어 개발의 실제적인 첫 단계로 개발 대상에 대한 사용자의 요구사항을 이해하고 명세화하는 활동을 의미함.
| 요구사항 분석 | 문제인식 - 사용자와 면담, 설문 조사 및 협조, 각종 문서 검토 등 통행 요구사항 수집 평가와 종합 - 추출된 요구사항에 대한 정보를 평가하고 여러가지 해결책을 종합 모델 제작 - 평가와 종합을 바탕으로 자료와 제어의 흐름, 기능 처리, 동작 행위, 정보 내용 등을 이해하기 쉽도록 모델로 작성 문서화와 검토 - 소프트웨어의 기능, 성능, 제약 조건 등에 대하여 명세 후 검토 |
| 요구사항명세서 | 요구사항 분석 단계에서 분석된 여러 결과를 바탕으로 소프트웨어의 기능, 제약 조건, 성능, 참조 자료 등을 기술한 문서 요구사항 분석서와 혼용하여 사용하기도 함. |
● 객체지향 프로그래밍(Object Oriented Programming)의 구성
- Method : 객체가 수행하는 기능으로 객체가 갖는 데이터를 처리하는 알고리즘
- Object : 클래스의 인스턴스, 자신 고유의 데이터를 가지며 클래스에서 정의한 행위를 수행
- Class : 공통된 특성과 연산을 갖는 객체의 집합, 같은 종류의 집단에 속하는 속성과 행위를 정의 한 것
- Message : 객체들 간 상호작용을 하는데 사용되는 수단, 객체에게 행위 지시를 하는 명령으로 객체간의 통신
● 객체지향의 특징
| 캡슐화 (Encapsulation) |
속성과 메서드를 하나로 묶어서 객체로 구성 Readability 향상 → 유지보수 용이 재사용성이 높은 S/W 개발 가능 내부 자료의 일관성 유지 객체 간 인터페이스 이용, 종속성 최소화 |
| 추상화 (Abstraction) |
공통 성질을 추출하여 슈퍼클래스로 구성 객체 중심의 안정된 모델을 구축 현실 세계를 자연스럽게 표현 분석의 초점이 명확해짐 |
| 다형성 (Polymorphism) |
동일한 이름의 여러 오퍼레이션(메서드)를 다른 사양으로 정의 가능 Overloading : 매개변수의 수 또는 타입을 달리하여 구분 Overriding : 부모클래스의 메서드를 재정의 |
| 정보은닉 (Information Hiding) |
캡슐화된 항목을 다른 객체로부터 감춤 메시지 전달에 의해 다른 클래스 내의 메서드가 호출 |
| 상속성 (Inheritance) |
부모클래스의 속성과 메서드를 상속받아 사용 부모와 자식 클래스 간의 관계가 슈퍼클래스와 서브클래스로 유지 부모클래스는 추상적이며, 자식클래스는 구체적 성질을 가짐 |
● 객체지향 분석 방법론
객체지향 분석은 사용자의 요구사항을 분석하여 요구되는 사항과 관련된 모든 객체, 클래스와 연관된 속성, 연산, 관계 등을 정의하여 모델링하는 작업으로 객체지향 분석의 목적은 클래스를 식별하는 것
Rumbaugh, Booch, Coad와 Yourdon, Wirfs-Brock 방법론 등이 있음.
▶ Rumbaugh 방법 (OMT, Object Modeling Technique)
가장 일반적으로 사용되는 방법으로 분석 활동을 객체모델, 동적모델, 기능모델로 나누어 수행하며, 모든 소프트웨어 구성 요소를 그래픽 표기법을 활용하여 모델링하는 기법
- 객체모델링 : 정보 모델링이라고도 하며, 시스템에서 요구되는 객체를 찾아내어 속성과 연산 식별 및 객체들 간의 관계를 규정한다. 실세계 문제 영역으로부터 객체와 클래스를 추출해 그들 간의 관계를 연관화, 집단화, 일반화 중심으로 규명한다. 클래스의 속성과 연산을 함께 표현함으로써 시스템의 정적 구조를 생성한다.
- 동적모델링 : 상태 다이어그램을 사용하여 시스템의 행위를 기술하는 모델링
- 기능모델링 : 자료흐름도(DFD)를 이용, 다수의 프로세스들 간의 자료 흐름을 중심으로 처리 과정을 표현. 어떤 데이터를 입력하면 어떤 결과를 구할 것인지 표현
▶ Booch 방법
미시적 개발 프로세스와 거시적 개발 프로세스를 모두 포함하여 사용. 클래스와 객체들을 분석 및 식별하고 클래스의 속성과 연산을 정의. 클래스와 객체의 의미를 식별, 클래스와 객체들의 관계를 식별, 클래스와 객체를 구현. 각 작업에 대한 다이어그램, 클래스 계층 정의, 클래스들의 클러스터링 작업을 수행. Use Case를 강조하여 사용하는 분석 방법
▶ Coad와 Yourdon 방법
객체지향 분석 방법론 중 E-R 다이어그램을 사용하여 객체의 행위를 모델링하며, 객체 식별, 구조 식별, 주제 정의, 속성과 인스턴스 연결 정의, 연산과 메시지 연결 정의 등의 과정으로 구성
▶ Wirfs-Brock 방법
분석과 설계 간의 구분이 없고 고객 명세서를 평가해서 설계 작업까지 연속적으로 수행하는 기법
● 자료사전
자료사전 = 자료흐름을 구성하는 자료항목, 자료에 대한 의미, 자료저장소를 구성하는 자료항목, 자료원소의 단위 및 값을 가지고 있음
구조적 분석에서 자료사전 작성시 - 갱신하기 쉬워야 함, 이름으로 정의를 쉽게 찾을 수 있어야 함. 정의하는 방식이 명확해야 함.
| = | 자료의 정의 |
| + | 자료의 연결 |
| () | 자료의 생략 |
| { | } | 자료의 선택 |
| { } | 자료의 반복 |
| ** | 자료의 설명 |
● 요구사항 명세기법
| 구분 | 정형명세 | 비정형명세 |
| 기법 | 수학적 기반/모델링 기반 | 상태/기능/객체 중심 명세 기법 |
| 종류 | Z, VDM, Petri-Net, CSP, CCS, LOTOS | FSM, Decision Table, ER 모델링, State Chart, UseCase-사용자기반 모델링 |
| 장점 | 시스템 요구특성 정확, 명세 간결, 명세/구현의 일치성 | 명세작성 이해 용이, 의사전달 방법 다양성 |
| 단점 | 낮은 이해도, 이해관계자의 부담 가중 | 불충분한 명세기능, 모호성 |
상태모형 기반(모델 기반) - Z, VDM, Decision Table, Event Table, Transition Table, FSM, Petri Net
● 자료흐름도(Data Flow Diagram)
자료흐름도 = 도형화된 도구를 이용해 정형화된 분석 절차에 따라 사용자 요구사항을 파악하고 문서화하는 분석 기법, 버블 차트라고도 함.
| 구성요소 | 의미 | 표기 | |
| Yourdon/DeMarco | Gane/Sarson | ||
| 처리 (process) | 입력된 자료를 출력으로 변환하는 것으로 프로세스라고 하고 원 안에 처리 명칭을 기술 |  |
 |
| 자료 흐름 (data flow) | 발생지, 종착지, 처리 및 저장소 사이에서 자료의 흐름을 나타내며, 화살표 위에 자료의 명칭 기술 |  |
|
| 자료 저장소 (data store) | 시스템 상의 자료 저장소를 나타내며 평행선 안에 자료 저장소 명칭을 기술 |  |
 |
| 단말기 (terminator) | 시스템에 필요한 자료가 입력되는 발생지와 시스템에서 처리된 자료가 출력되는 종착지 또는 외부에 존재하는 사람이나 조직을 나타내며, 사각형 안에 발생지나 종착지 명칭 기술 |  |
 |
● UML(Unified Modeling Language)
UML = 객체 지향 소프트웨어 개발 과정에서 산출물을 명세화, 시각화, 문서화할 때 사용되는 모델링 기술과 방법론을 통합하여 만든 표준화된 범용 모델링 언어
특징 :
| 가시성 | 반복적/점진적으로 구체화하여 소프트웨어의 가시성을 제공 |
| 구현 | 다양한 프로그래밍 언어로 표현하며 이미 구축되어 있는 소스코드를 UML로 역변환하여 분석하는 역공학(Reverse Engineering)을 제공 |
| 명세화 | 단순 표기법이 아닌 구현에 필요한 개발 요소 및 기능에 대한 명세를 제공 |
| 문서화 | 개발규모, 개발 프로세스 및 언어와 무관하게 개발자간 의사소통 도구를 제공 |
● UML의 구성요소 :
사물 - 구조/행동/그룹/주해 사물
관계 - 의존/연관/일반화/실체화 관계
다이어그램 - 유즈케이스, 클래스 등 주요 다이어그램
● UML모델 유형
| 실체화 | 객체들 사이의 의미적 관계로서 한 객체가 다른 객체의 계약을 지정 의존과 일반화의 혼합이며, 표기법도 의존과 일반화에서 참고 인터페이스와 인터페이스에 오퍼레이션이나 서비스를 제공하는 클래스나 컴포넌트 사이의 관계를 지정하기위해 사용 |
| 일반화 | 일반화된 사물과 좀 더 특수화된 사물과의 관계 부모 객체가 사용되는 어느 곳에서나 자식 객체가 사용될 수 있다는 것을 의미 부모 자식 관계를 표현할 때 일반화를 사용 주로 클래스와 인터페이스 사이에서 상속 관계를 보여주기 위해 사용 |
| 의존 | 두 사물 간의 의미적 관계, 한 사물의 명세서가 바뀌면 그것을 사용하는 다른 사물에게 영향을 끼치는 것을 의미하는 개념 표기는 점선으로 된 직선을 사용하고, 의존하고 있는 사물을 향하고 있음 의존은 한 클래스가 다른 클래스를 오퍼레이션의 매개변수로 사용하는 경우에 주로 나타남 |
| 연관 | 구조적 관계로서 어느 한 사물 객체와 다른 사물 객체의 연결을 의미 두 클래스가 서로 연결되어 연관이 있다면, 한쪽 객체에서 다른 쪽 객체로 이동할 수 있으며 반대도 가능 한 연관의 다른 양쪽 끝이 같은 클래스를 향해 원을 그리며 순환하는 것도 가능, 쌍방 연관, 다수연관 이름과 역할을 가질 수 있으며, 객체간 구조적 관계를 표현하기 위해 다중성을 표현하기도 함 표기는 두 클래스를 연결하는 실선으로 표현 |
● UML 클래스간 관계
| 일반화 관계 | 객체지향 개념에서 상속관계라고 하며, 한 클래스가 다른 클래스를 포함하는 상위 개념일 때 이를 IS-A 관계라고 하고 UML에서는 일반화 관계로 모델링함. |  |
| 연관 관계 | 클래스들이 개념상 서로 연결됐음을 나타내며, 보통은 한 클래스가 다른 클래스에서 제공하는 기능을 사용하는 상황일 때 표시한다. |  |
| 의존 관계 | 연관 관계와 같이 한 클래스가 다른 클래스에서 제공하는 기능을 사용할 때 나타내며, 연관 관계와 차이점은 두 클래스의 관계가 한 메서드를 실행하는 동안과 같은, 매우 짧은 시간만 유지된다는 점이다. |  |
| 집단(집합) 관계 | 클래스들 사이의 전체 또는 부분 같은 관계를 나타내며, 전체 객체의 라이프 타임과 부분 객체의 라이프 타임은 독립적이다. 즉 전체 객체가 사라져도 부분 객체는 남아있음. |  |
| 집단(합성) 관계 | 클래스들 사이의 전체 또는 부분 같은 관계를 나타내며 전체 객체의 라이프 타임과 부분 객체의 라이프 타임이 의존적이다. 즉, 전체 객체가 사라지면 부분 객체도 함께 사라짐. |  |
| 실체화 관계 | 책임들의 집합인 인터페이스와 이 책임들을 실제로 실현한 클래스들 사이의 관계를 나타냄. |  |
● 유즈케이스 다이어그램 구성요소
액터(Actor) - 시스템의 외부에 있고 시스템과 상호작용을 하는 사람, 시스템을 의미
유즈케이스(Use case) - 사용자 입장에서 바라본 시스템의 기능으로 시스템이 액터에게 제공해야 하는 기능을 시스템의 요구사항으로 나타냄
관계(Relation)
- 포함관계 : 하나의 유즈케이스가 다른 유즈케이스의 실행을 전제로 할 때 형성되는 관계로 포함 대상 유즈케이스를 반드시 실행되어야 하는 경우에 적용하며 포함되는 유즈케이스 방향으로 화살표를 점선으로 연결하고 <<include>>라고 표기
- 확장관계 : 하나의 유즈케이스와 다른 유지케이스 사이에 형성되는 관계로 특정 조건에 따라 확장 대상 유즈케이스를 수행하는 경우에 적용하며, 확장 대상 유즈케이스 반대방향으로 화살표를 점선으로 연결하고 <<extend>>라고 표기
● UML 다이어그램의 종류
| 구조적(Structural) 다이어그램 | class | 시스템 내 클래스들의 정적 구조를 표현 클래스는 객체들의 집합으로 속성과 동작으로 구성 |
| object | 클래스의 여러 객체 인스턴스를 나타내는 대신 실제 클래스를 사용 관계 있는 모든 인스턴스를 표현 |
|
| component | 코드 컴포넌트에 바탕을 둔 코드의 물리적 구조 표현 컴포넌트는 논리적 클래스 혹은 클래스 자신의 구현에 대한 정보를 포함하고 실질적인 프로그램 작업에 사용 |
|
| deployment | 시스템 하드웨어와 소프트웨어 간의 물리적 구조를 표현하며, 실질적인 컴퓨터와 디바이스 간의 관계를 표현하는데 이용 컴포넌트 사이의 종속성을 표현 |
|
| package | 시스템 계층적인 구조 표현 클래스들로 이루어진 패키지와 그들 간의 의존 관계를 보여줌 |
|
| composite structure | 전체 클래스 안에 각 컴포넌트 클래스 표현 클래스 내부 구조 파악에 용이 |
|
| 행위(behavioral) 다이어그램 | use case | 사용자의 입장에서 본 시스템의 행동 표현 유즈케이스는 시스템의 기능적인 요구를 정의 |
| state | 클래스의 객체가 가질 수 있는 모든 가능한 상태와 상태간의 전이를 표현 진입조건, 탈출조건, 상태전이에 필요한 사건 등 자세한 사항이 기술 설계단계에서 클래스 객체의 동적인 행동 방식을 표현하는데 사용 |
|
| activity | 행위의 순서적 흐름을 표시 순서도나 병렬적인 처리를 요하는 행위를 표현할 때 사용 |
|
| 상호작용(interaction) 다이어그램 | sequence | 객체와 객체간의 상호작용을 메시지 흐름으로 표시 오브젝트 사이에 메시지를 보내는 시간 또는 순서를 보여주기 위해 사용 |
| communication | 상호작용에 참여하는 객체/컴포넌트 간의 관계를 명시적으로 표현 | |
| interaction overview | 활동 다이어그램과 시퀀스 다이어그램 혼합 상호작용에 대한 제어흐름을 표현 |
|
| timing | 시간적 제약과 객체상태 변화를 표현 인스턴스간의 상태전이와 상호작용을 시간 제약으로 표현 |
● UML 접근 제한자
+ = public
- = private
# = protected
~ = package
● UML 액티비티 다이어그램의 노드 종류
- Action/Activity, Object node, Control flow, Object flow, Initial node, Final node, Decision node, Merge node, Fork node, Join node
● 유즈케이스 실현에 필요한 분석클래스
하나의 유즈케이스 실현을 위해 3개 이상의 클래스가 역할 기준으로 도출되어야 하며, 유즈케이스 별로 실현에 필요한 클래스가 추적 가능해야 클래스 누락 여부 확인가능
| 엔티티(Entity) 클래스 |  |
시스템에서 계속 추적해야 할 자료가 들어있는 클래스 책 주문 정보는 데이터베이스에 계속 저장하고 취소하더라도 주문내역으로 저장할 만한 자료이므로 엔티티 클래스에 해당 고객, 주문 아이템에 관한 데이터 등도 영구적으로 시스템에서 기록되어야 할 자료이므로 엔티티 클래스로 분류 |
| 경계(Boundary) 클래스 |  |
주로 시스템 외부의 액터와 상호작용하는 클래스로 사용자 인터페이스를 제어하는 역할 액터와 연결된 시스템 인터페이스를 나타내며 각 사용 사례에서 액터는 적어도 하나의 경계 클래스와 인터페이스 경계클래스는 액터로부터 정보를 수집하여 엔티티 객체나 제어 객체가 사용할 수 있는 형태로 변경 |
| 제어(Control) 클래스 |  |
경계클래스와 엔티티 클래스 사이에 중간 역할 제어클래스는 사용 사례의 초기에 생성되고 끝까지 존재하며 경계클래스로부터 정보를 받아 엔티티클래스에 전달 |
● 애자일(Agile) 개발 방법론
- 애자일 방법은 어느 특정 개발 방법론을 가리키는 말은 아니며 애자일(Agile: 기민한, 좋은 것을 빠르고 낭비없게 만드는 것) 개발을 가능하게 해 주는 다양한 방법론 전체를 일컫는 말.
- 지속적인 요구사항의 분석, 반영을 통해 변화에 신속하게 대응하는 개발방법론
- 소프트웨어 개발 방법에 있어서 아무런 계획이 없는 개발 방법과 계획이 지나치게 많은 개발 방법들 사이에서 타협점을 찾고자 등장하게 된 방법론.
- Agile 방법론의 테스트는 잦은 개발-테스트 주기를 통하여 많은 시간과 비용이 들어가기 전에 기능을 검증하게 됨.
● 애자일 선언문
- 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아감.
- 공정과 도구보다 개인과 상호작용 / 포괄적인 문서보다 작동하는 소프트웨어 / 계약 협상보다 고객과의 협력 / 계획을 따르기보다 변화에 대응하기를 가치있게 여긴다.
● 애자일 소프트웨어의 12가지 원칙 :
- 가치있는 소프트웨어를 빠르게 그리고 지속적으로 제공해서 고객을 만족시키는 것을 가장 중요하게 생각.
- 개발의 후반부일지라도 요구사항 변경을 환영. 애자일 프로세스는 변화를 활용해서 고객의 경쟁력을 높이는데 기여
- 새로운 소프트웨어는 몇 주나 몇 달의 주기로 자주 제공하며 간격은 짧을수록 좋음
- 프로젝트가 진행되는 동안 사업부서 사람들과 개발자는 매일 만나서 함께 일을 진행
- 의욕 있는 사람들 위주로 팀을 구성하고, 그들이 필요로 하는 환경과 적극적인 지원 제공 후 일을 완수할 거라는 믿음
- 개발팀으로, 혹은 개발팀 내에서 정보를 전하는 가장 효율적, 효과적인 방법은 서로 얼굴을 마주하고 소통하는 것
- 업무 진척을 측정하는 기본 척도는 작동하는 소프트웨어
- 애자일 프로세스들은 지속 가능한 개발을 장려, 후원자/개발자/사용자는 일정한 속도를 계속 유지해야 함
- 기술적 우수성과 좋은 설계에 대한 꾸준한 관심이 기민성을 높임
- 단순성(하지 않아도 되는 일의 양을 최대화하는 기술) 필수적
- 최고의 아키텍처, 요구사항, 설계는 자기 조직적인 팀에서 나타남
- 팀은 정기적으로 더 효과적으로 일할 방법을 고민하고 이를 통해 이른 결론에 따라서 팀이 어떻게 움직일지 조율하고 조정
● 주요 애자일 개발 방법론 :
| XP (eXtreme Programming) |
의사소통 개선과 즉각적인 피드백에 의한 단순한 코딩으로 S/W 품질을 높이기 위한 방법론 1 ~ 3주 반복 주기 5가지 가치 : 용기, 단순성, 의사소통, 피드백, 존경 12가지 실천항목 |
| SCRUM | 매일 정해진 시간에 정해진 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심의 방법론 30일마다 동작 가능한 제품을 제공하는 스프린트 백로그(backlog) : 제품과 프로젝트에 대한 요구사항 스프린트(sprint) : 30일 단위의 짧은 개발기간으로 분리하여 반복적 수행 스크럼미팅 : 매일 스크럼 미팅으로 오늘과 내일 해야 할 일의 계획수립 스크럼마스터 : 프로젝트 리더, 스크럼 수행 시 문제 인지 및 이를 해결하려고 노력하는 사람 |
| Lean | 린 시스템의 품질 기법을 소프트웨어 개발 프로세스에 적용하여 프로세스의 낭비요소를 제거 후 결과 측정, 성과를 분석하여 소프트웨어의 품질을 향상시키는 개발방법론 7가지 원칙 : 낭비 제거, 품질 내재화, 지식 창출, 늦은 확정, 빠른 인도, 사람 존중, 전체 최적화 |
| FDD (Feature Driven Development) |
개발을 상품이나 서비스 단위가 아니라 신규 기능 단위로 하는 개발 방법론 기능별 개별적으로 수행해야 하는 구체적이고 짧은 단계의 작업 하나의 기능 개발을 위해 전체 팀에서 필요한 내용을 중재하고 전체 시스템의 흐름을 정의할 수 있는 아키텍트의 역할 필요 각 개발 컴포넌트별 코디네이션이 중요 feature마다 2주정도의 반복 개발 실시 Peter Coad가 제창한 방법론 UML을 이용한 설계 기법과도 밀접한 관련 |
전통적인 소프트웨어 개발방식과 Agile 개발 방식의 비교
| 구분 | 전통적인 개발방식 | Agile 개발방식 |
| 개념 | 엄격한 프로세스 기반 정형화된 역할 및 활동 강조 | 프로젝트 관계자간 상호 작용을 중심으로 반복적인 점검과 테스트 |
| 계획 수립 | 확정된 범위, 초기에 상세 요구사항 확정, 초기 일정계획 수립 | 유동적인 범위 및 상세 요구사항 조정, 주기적인 상세 계획 |
| 개발 및 테스트 | 분석/설계/구현/테스트를 순차적으로 수행 | 반복적인 단위로 실행 소프트웨어를 전달하여 적시설계 및 개발 |
| 프로세스 뷰 | 정형화되고 상세화됨 | 유연하고 간소, 프로젝트 상황에 따라 주기적 조정 |
| 업무 수행 형태 | 관리자 주도적 명령과 통제, 개인 단위로 업무 수행 | Self - Organizing 팀 중심으로 업무를 수행 |
| 조직 | 분업화되고 역할이 한정 | 전문가가 다기능을 수행 |
| 팀관리 | 지시 및 감시, 경쟁, 개별평가 | 업무 수행 및 코칭, 팀 평가 |
| 문서화 | 상세한 문서화 강조 | 문서화보다 코드 강조 |
| 성공요소 | 계획 준수 | 고객 가치 전달 |
● 모델링(Modeling)
정의 : 실세계의 물리현상을 특정한 목적에 맞추어 이용하기 쉬운 형식으로 표현하는 일
역할 : 실세계 문제 상황에 대한 이해를 증진시키고 해결책 설명.
사례 : 객체지향 개발 방법론에서는 UML사용
● 사용자 인터페이스 (UI, User Interface)
| 사용자 인터페이스 | UI는 사람들이 컴퓨터, 시스템, 기기, 도구 등 그 사이에서 일어나는 상호작용을 매개하는것 사람과 사물 또는 시스템, 기계, 컴퓨터 등 그 사이에서 의사소통을 할 수 있도록 일시적 또는 영구적인 접근을 목적으로 만들어진 물리적, 가상적 매개체 사용자 인터페이스는 디스플레이 화면, 키보드, 마우스, 문자, 아이콘, 도움말 등에 해당하고, 사용자들과 상호 작용을 하도록 설계된 모든 정보관련 고안품을 포함하여, 응용프로그램이나 웹사이트 등이 상호작용을 초래하거나 그것에 반응하는 방법 등을 의미 |
| UI의 목적 | 좋은 UI는 심리학과 생리학에 기반하여 사용자가 필요로 하는 요소를 쉽게 찾고 사용하며 그 요소로부터 명확하게 의도한 결과를 쉽게 얻어낼 수 있어야 함 UI는 상호작용 수단과 방식을 제공 |
| UI 종류 | CUI (Character based UI) :문자방식의 명령어 입력 사용자 인터페이스 GUI (Graphic UI) : 그래픽 환경 기반의 마우스 입력 사용자 인터페이스 NUI (Natural UI) : 사용자의 말과 행동 기반 제스처 입력 인터페이스 등 |
| UI 기본 원칙 | 직관성, 유효성, 학습성, 유연성 직관성은 앞의 구조를 큰 노력 없이도 쉽게 이해하고, 쉽게 사용할 수 있게 제작해야 하고, 용이한 검색, 쉬운 사용성, 일관성이 있어야 한다는 원칙 유효성은 정확하고 완벽하게 사용자의 목표가 달성될 수 있도록 제작해야 한다는 원칙 학습성은 초보와 숙련자 모두가 쉽게 배우고 사용할 수 있게 제작해야 하고, 쉽게 학습, 쉬운 접근, 쉽게 기억해야 한다는 원칙 유연성은 사용자의 인터랙션을 최대한 포용하고, 실수를 방지할 수 있도록 제작해야 하고, 오류 예방, 실수 포용, 오류 감지가 가능하도록 해야 한다는 원칙 |
● UI 표준 & UI 지침
UI 표준 = 조직의 브랜드나 정체성과 일치되는 디자인 철학과 원칙이 기술되어 UI 표준이 정리되고 공통으로 사용하는 UI/GUI 요소 및 배치규칙 등을 정의
UI 지침 = 웹/모바일 서비스의 구축 시 효율적인 정보 전달이 가능하도록 사용자 인터페이스 설계에서 지켜야 할 세부사항을 규정하는 것
● 스타일 가이드
- UI를 만들때 기본 원칙, 레이아웃, 엘리먼트 등 각종 규칙들의 기준이 되는 집합을 의미
- 웹 스타일 가이드의 목적은 웹사이트의 통일되고 일관된 사용자 경험을 구현하고, 사이트의 추가개발 및 유지보수의 편리성을 높이는 것. 체계적이고 일관된 사용자 경험은 결과적으로 사용자들에게 사이트의 일관되고 통일된 아이덴티티와 브랜드 이미지를 형성함.
- UI 설계 과정 중 디자이너와 개발자가 최종적으로 참고하는 설계 산출 문서로 정책, 프로세스 및 콘텐츠의 구성, 와이어프레임, 기능 정의, 데이터베이스의 연동 등 서비스 구축을 위한 대부분의 정보가 수록되어 있는 것은 스토리보드이다.
● UI 화면 설계 구분
| 구분 | 스토리보드 | 와이어프레임 | 프로토타입 |
| 개념 | 정책, 프로세스 및 콘텐츠의 구성, 와이어프레임(UI,UX), 기능 정의, DB의 연동 등이 수록된 설계 산출물을 말함 | 이해관계자들과의 의사소통 또는 서비스의 간략한 흐름을 위해 화면 단위의 레이아웃을 설계하는 작업 | 와이어프레임 또는 스토리보드의 정적화면에 동적효과를 적용하여 실제 구현된 것처럼 테스트해 볼 수 있다 |
| 도구 | 파워포인트, 키노트, 스케치 등 | 손그림, 파워포인트, 키노트, 스케치, 일러스트, 포토샵 등 | HTML/CSS, 네이버, 프로토나우, 카카오 오븐 등 |
● 프로토타입
프로토타입 모델의 순차적 과정 :
프로토타입 모형의 장단점
장점 :
- 사용자 요구사항의 정확한 파악에 용이
- 발주자와 개발자에 공통의 참조모델 제공으로 시스템 이해와 품질 향상
- 발주자와 개발자 간 의사소통 원활
- 정확한 요구사항 파악으로 인한 위험감소
단점 :
- 미리 제작된 소프트웨어를 사용할 경우, 실제 소프트웨어와의 차이가 발생할 수 있음
- 단기간에 제작해야 하기에 비효율적인 언어나 알고리즘을 사용할 수 있음
- 발주자가 프로토타입 모형의 시제품을 완성 제품으로 오해 할 수 있음
● UI 흐름설계 단계 수행하는 방법
| 1. 화면에 구현되어야 할 기능 정의 | 기능적 요구사항에 대한 설명 정리 - 입출력 데이터/ 정보의 등록, 수정 삭제 등 기능/ 이벤트에 따른 수행 기능 비기능적 요구사항에 대한 설명 정리 - 플랫폼 및 적용 기술 등 시스템 환경적 요구 기능/ 처리속도 등 시스템 성능/ 시스템 제약사항 |
| 2. 화면의 입력 요소 파악 | 화면에서 수행되어야 할 기능 화면의 입력 항목 화면간 이동과 흐름 |
| 3. UI요구사항에 대한 유즈케이스 설계 | 액터별 시나리오 구상 액터의 상호작용에 따른 세분화 |
| 4. 기능 및 양식의 규칙 정의 | Input Box 적용 규칙 정의 Control Box 적용 규칙 정의 Radio Box 적용 규칙 정의 Check Box 적용 규칙 정의 |
● UI 설계 단계
문제 정의 - 사용자 모델 정의 - 작업 분석 - 컴퓨터 오브젝트 및 기능 정의 - 사용자 인터페이스 정의 - 디자인 평가 순으로 진행
| 문제 정의 | 시스템의 목적을 기술하고 해결해야 할 문제를 정의 |
| 사용자 모델 정의 | 사용자의 특성을 명확히 하지 않고는 시스템의 사용성을 확보할 수 없으므로 사용자의 특성을 결정 사용자의 컴퓨터 소프트웨어와 작업에 대한 지식 정도에 따라 초보자, 중급자, 숙련자로 분류 가능 |
| 작업 분석 | 항상 해결해야 할 문제를 정제하고 사용자의 특징들을 상세화하며 시스템을 통해 수행해야 할 작업들을 정의 |
| 컴퓨터 오브젝트 및 기능 정의 | 분석한 작업을 컴퓨터의 어떤 사용자 인터페이스를 통해 표현할 것인지를 정의 실제 사용자는 시스템을 이용해 작업할 경우, 컴퓨터 오브젝트를 통해 수행 |
| 사용자 인터페이스 정의 | 컴퓨터나 작업 수행 방법에 대하여 상호작용하는 오브젝트를 선택하고 시스템의 상태를 명확히 정의 상호작용 오브젝트란 작업을 위한 마우스나 키보드, 스크린 등의 물리적인 입력이나 출력 디바이스를 의미 |
| 디자인 평가 | 설계한 인터페이스가 분석한 작업에 맞게 잘 설계가 되었는지, 사용자의 능력이나 지식에 대해 적당한지, 사용자가 쓰기 쉽고 편리한지 등을 평가 사용성 평가 실험을 통해 설계한 인터페이스에 대한 사용성 평가를 할 수 있음 평가 방법론은 GOMS(Goals, Operators, Methods, Selection rules)나 휴리스틱 등 사용성 공학 방법론이 활용됨 |
● UI 설계 도구의 유형
| 문서 작성 도구 및 드로잉 전문 도구 | 일반 문서 작성 도구나 웹사이트, 윈도우 컴포넌트, 블록 다이어그램 등 다양한 기능을 제공하는 드로잉 도구 |
| 화면 설계를 위한 전문 도구 | 다양한 드로잉을 지원하기보다는 화면 스케치를 위한 단순하고 전문화된 기능을 제공하는 도구 |
| UI 설계 및 개발 전문 도구 | UI 패턴과 UI 모델링, UI 디자인 및 소스 코드 생성 등 생산성 향상과 화면의 품질 확보를 위한 전문 도구 |
| 해당 UI 플랫폼에 포함된 도구 | 해당 UI 플랫폼에서 프로토타이핑을 하고 이를 이용하여 설계에 관한 협의를 할 수 있을뿐 아니라 바로 코딩이 가능한 도구 |
● 비기능 요구사항
기능 요구사항은 요건에 대한 시스템의 행동, 시스템이 동작하는 내용에 대해 정의한 것 등 시스템의 기능과 관련된 요구사항을 의미함. 기능과 관련된 요구사항 외의 기타 요구사항을 모두 비기능 요구사항이라고 함
비기능 요구사항의 예시 :
| 시스템 장비 구성 요구사항 | 하드웨어, 소프트웨어, 네트워크 등의 도입 장비 내역 등 |
| 성능 요구사항 | 처리속도 및 시간, 처리량, 동적/정적 용량, 가용성 등 |
| 인터페이스 요구사항 | 시스템 인터페이스와 사용자 인터페이스에 대한 요구사항 |
| 데이터 요구사항 | 초기자료 구축 및 데이터 변환을 위한 대상, 방법, 보안이 필요한 데이터 등 |
| 테스트 요구사항 | 테스트와 관련된 요구사항 |
| 보안 요구사항 | 정보 자산의 기밀성과 무결성을 확보하기 위해 필요한 사항 |
| 품질 요구사항 | 품질 항목, 품질 평가 대상 및 목표 |
| 제약사항 | 기술/표준/업무/법제도 등 제약조건 등을 파악하여 기술 |
| 프로젝트 관리 요구사항 | 관리 방법 및 추진 단계별 수행방안에 대한 요구사항을 기술 |
| 프로젝트 지원 요구사항 | 지원사항 및 방안에 대한 요구사항을 기술 |
기능적 요구사항과 비기능적 요구사항 비교 :
| 구분 | 기능적 요구사항 (Functional Requirement) |
비기능적 요구사항 (Non-functional Requirement) |
| 개념 | 시스템에서 제공되어야 할 특정 기능을 정의 | 시스템의 전체적 품질이나 기능적 요구사항의 구현시 고려해야하는 제약사항 |
| 내용 | 데이터 모델 : 개념적인 모델의 샅태를 구체화한 것으로 생성, 삭제 등의 실행을 정의 데이터 흐름 처리모델 : 시스템 행위가 어떻게 이루어지는가를 표현하여, 데이터 모델의 입출력이 데이터의 일부분으로 사용 프로세스모델 : 병행, 상호작용, 다른 프로세서들 간의 동기화 등의 사건과 활동을 서술 |
S/W 뿐만 아니라 시스템 전체에 대한 요구사항임 성능 : 응답속도, 자원 사용량 보안 : 침입대응, 사용자인증/권한 아키텍처 : 확장성, 유연성 안정성 : 장애대응, 서비스연속성 |
● 감성공학기술
감성공학 = 인체의 특징과 감성을 제품설계에 최대한 반영시키는 기술
1. 인간공학/인자공학 등 인간의 특성을 파악하려는 연구에 기본을 둔 생체 측정 기술
2. 인간 특성에 적합하도록 사용자 인터페이스를 실현하기위한 기술로서 센서 공학/퍼지 뉴럴 네트워크 기술/신경망 기술 등 인간의 오감 센서 및 감성 처리 기술
3. 산업 디자인 등의 감성 디자인 기술
4. 마이크로 기구 설계/극소기계 응용 등 마이크로 가공 기술
5. 사용성 평가 기술/가상현실 기술 등으로서 인간에 대한 적합성을 판단하고 새로운 감성을 창출하기 위한 기술
① 감성공학 1류 : 인간의 감성을 형용사로 표현할 수 있다고 보고 인간의 감성 이미지를 측정하는 방법. 이를 통해 제품에 대한 이미지를 조사/분석하여 제품의 디자인 요소와 연계시킴
② 감성공학 2류 : 개인의 연령, 성별 등의 개별적 특성과 생활 방식으로부터 개인이 갖고 있는 이미지를 구체화하는 방법. 감성의 심리적 특성을 강조한 접근 방법. 또한 감성의 개인성에 중점을 둔 문화적 감성의 일부를 반영하기도 함
③ 감성공학 3류 : 기존의 감성적 어휘 대신 공학적인 방법으로 접근하여 인간의 감각을 측정하고, 이를 바탕으로 수학적 모델을 구축하여 활용. 대상이 되는 제품의 물리적 특성과 인간의 감각이 객관화된 지표 사이의 연관성을 분석하여 제품 설계에 응용할 수 있으며, 측정 시 감성의 생리적 특성을 중시함.
● 객체지향 소프트웨어 설계 원칙(SOLID)
| 단일 책임 원칙 (SRP, Single Responsibility Principle) |
객체는 단 하나의 책임만을 가져야 함. 어떤 클래스를 변경해야 하는 이유는 오직 하나뿐이어야 하며 같은 이유로 변화하는 것끼리 묶고, 다른 이유로 변화하는 것끼리는 분리한다. |
| 개발 폐쇄 원칙 (OCP, Open-Closed Principle) |
기존의 코드를 변경하지 않으면서 기능을 추가할 수 있도록 설계가 되어야 함 소프트웨어 개체(Classes, Modules, Functions 등)는 확장에는 열려있고 수정시에는 닫혀있어야 함. |
| 리스코프 치환의 원칙 (LSP, Liskov Substitution Principle) |
일반화 관계에 대한 것으로 자식 클래스는 최소한 자신의 부모 클래스에서 가능한 행위는 수행할 수 있어야 함 하위클래스 및 타입들은 상위 타입들이 사용되는 곳에 대체될 수 있어야 하는 설계 원칙이다. |
| 인터페이스 분리의 원칙 (ISP, Interface Segregation Principle) |
인터페이스를 클라이언트에 특화되도록 분리하라는 설계 원칙 하나의 일반적인 인터페이스보다 구체적인 여러개의 인터페이스가 낫다. |
| 의존성 뒤집기의 원칙 (DIP, Dependency Inversion Principle) |
의존 관계를 맺을 때 변화하기 쉬운 것 또는 자주 변화하는 것보다는 변화하기 어려운 것, 거의 변화가 없는 것에 의존하라는 것이다. 추상화된 것에 의존하게 만들고 구체 클래스에 의존하도록 만들지 않도록 함 |
● 객체지향 기법 및 모듈화
모듈화 = 소프트웨어의 성능을 향상시키거나 시스템의 수정 및 재사용, 유지 관리를 용이하게 하여 프로그램을 효율적으로 관리할 수 있도록 시스템을 분해하고 추상화하는 기법
객체지향 기법 :
- 추상화(Abstraction) = 공통 성질을 추출하여 슈퍼클래스로 구성, 객체 중심의 안정된 모델 구축, 현실 세계를 자연스럽게 표현, 분석의 초점 명확
- 정보은닉(Information Hiding) = 캡슐화 된 항목을 다른 객체로부터 숨김, 메시지 전달에 의해 다른 클래스 내의 메서드가 호출
모듈화 :
- 모듈의 독립성 판단 지표 = 응집도와 결합도
응집도는 내부의 구성 요소간 관계의 밀접 정도로 평가되며, 응집도가 높을수록 필요한 요소들로 구성되어지고 낮을수록 요소들 간의 관련성이 적은 요소들로 구성됨.
결합도는 어떤 모듈이 다른 모듈에 의존하는 정도를 측정하는 척도로 독립적인 모듈이 되기 위해서는 결합도가 낮아야함
모듈화의 원칙
- 정확성(Correctness) : 실제 시스템 구현시 필요한지 기능인지 여부를 알 수 있도록 정확하게 작성
- 명확성(Clarity) : 해당 기능에 대한 일관된 이해와 하나로 해석될 수 있도록 작성
- 완전성(Completeness) : 시스템의 구현 시 요구사항과 필요한 모든 것을 기술
- 일관성(Consistency) : 공통 기능 사이에 충돌이 발생하지 않도록 작성한다는 원칙
- 추적성(Traceability) : 해당 기능에 대한 요구사항의 출처와 관련 시스템 등 유기적 관계에 대한 식별이 가능하도록 작성한다는 원칙
구조(Structure) 모델링 : 소프트웨어를 구성하는 컴포넌트들의 유형, 인터페이스, 내부 설계 구조 및 이들의 상호연결 구조를 모델링함
행위(Behavior) 모델링 : 소프트웨어의 구성요소들의 기능들과 이들이 언제, 어떠한 순서로 기능을 수행하고 상호작용하는지 모델링함
| 모델유형 | 개요 | 내용 | 정적 요소 | 동적 요소 |
| 구조 모델 | 시스템의 구성 요소들과 이들 사이의 구조적인 관계와 특성들의 모델링 | 구성요소 : 프로시저, 데이터구조. 모듈. 파일구조 시스템 구조 : 구성 요소들의 연결 구조, 포함관계 |
구성 요소의 유형 및 유형 계통 구성 요소들의 배열, 결합 관계 구성 요소들의 인터페이스 구성 요소들의 상호 작용 패널 |
동적 생성 및 소멸 동적 결합/연결 위치 이동, 복제 |
| 행위 모델 | 시스템의 각 구성 요소들의 기능적 특성들에 대한 모델링 | 입/출력 데이터, 데이터 흐름. 데이터 변환, 데이터 저장 등 | 입력/출력 데이터 입출력 매핑 데이터 흐름 채널 |
제어 상호작용 프로토콜 상호 작용 실행 경로 상태전이 처리순서, 입/출력 순서, 알고리즘 |
| 시스템의 구성 요소들이 언제 어떠한 순서로 수행되는가와 같은 동적 특성들의 모델링 | 상태전이, 데이터 흐름경로, 사건발생 순서, 실행 경로 등 |
● 소프트웨어 아키텍처
소프트웨어 아키텍처 = 소프트웨어 시스템의 구조를 비롯한 시스템 개발에 중요한 영향을 미치는 결정들로, 소프트웨어 시스템 개발에서 특정 시스템에 대하여 요구되는 기능과 품질을 확보하고 또한 소프트웨어 시스템의 구축 및 지속적인 개선이 용이하도록 하는 역할을 함
| 소프트웨어 아키텍처의 역할 |
요구사항 분석 활동에 의해 도축된 요구사항을 모두 충족시킬 수 있는 시스템이 만들어지도록 하는 설계 활동으로서 설계 및 구현을 위한 구조적/비구조적 틀을 제공 틀이란 아키텍처 설계의 결과물로서 실행을 요구하는 결정 또는 모델을 의미 구조적 틀 : 시스템 개발을 위해 결정된 컴포넌트의 구조모델 비구조적 틀 : 구조모델 이외의 다른 아키텍처설계의 결정들 |
| 아키텍처 설계의 입력과 출력 | 시스템 개발은 모든 요구사항을 달성대상으로 하지만 아키텍처 설계는 아키텍처에 관련된 대표적인 요구사항들만이 주된 관심의 대상이며, 이와 같은 특별한 요구사항들이 아키텍처 드라이버임 설계와 결과는 아키텍처를 문서화한 아키텍처 문서가 주된 출력물이 되고 이에 대한 추가적인 관련사항을 정리한 아키텍처 가이드라인이 이차적인 출력물 |
● 소프트웨어 아키텍처 관련 용어
| 아키텍처 드라이버 | 시스템 요구사항 중 아키텍처에 영향을 주는 요구사항을 아키텍처 드라이버라 하며, 아키텍처 설계에 더 집중할 수 있기 위해 아키텍처 드라이버를 먼저 잘 식별해낸 후 아키텍처 설계에 효과적으로 반영 |
| 아키텍처 스타일 | 아키텍처 스타일은 아키텍처의 유형 적절한 아키텍처 스타일의 선택은 대상시스템의 개발을 효율적이고 효과적으로 만들 수 있음 |
| 아키텍처 패턴 | 반복적으로 발생하는 문제에 대해 미리 만들어진 솔루션 |
| 소프트웨어 아키텍처 프레임워크 | IEEE1471은 소프트웨어 구조에 대한 기술을 규정한 IEEE 표준 IEEE42010은 시스템 및 SW 엔지니어링 아키텍처 기술과 관련된 용어와 개념을 정의한 국제표준 |
● 아키텍처 패턴
1. 계층화 패턴 : N-티어 아키텍처 패턴이라고도 불림. 이는 하위 모듈들이 그룹으로 나눌 수 있는 구조화된 프로그램에서 사용할 수 있음. 각 하위 모듈들은 특정한 수준의 추상화를 제공하며, 각 계층은 다음 상위계층에 서비스 제공.
일반적인 정보 시스템에서 공통적으로 볼 수 있는 계층 4가지 : 프레젠테이션 계층 - UI 계층 / 애플리케이션 계층 - 서비스 계층 / 비즈니스 논리 계층 - 도메인 계층 / 데이터 접근 계층 - 영속 계층
활용 사례 : OSI 7 Layer, 일반적인 데스크톱 어플리케이션, E-Commerce 웹 어플리케이션
2. 클라이언트 - 서버 패턴 : 하나의 서버와 다수의 클라이언트, 두 부분으로 구성됨. 서버 컴포넌트는 다수의 클라이언트 컴포넌트로 서비스 제공. 클라이언트가 서버에 서비스를 요청하면 서버는 클라이언트에게 적절한 서비스를 제공하며 서버는 계속 클라이언트로부터의 요청 대기
활용 사례 : 이메일, 문서 공유 및 은행 등의 온라인 애플리케이션
3. 마스터 - 슬레이브 패턴 : 마스터와 슬레이브, 두 부분으로 구성됨. 마스터 컴포넌트는 동등한 구조를 지닌 슬레이브 컴포넌트들로 작업을 분산하고, 슬레이브가 반환한 결과 값으로부터 최종 결과 값을 계산함
활용 사례 : 데이터베이스 복제에서, 마스터 데이터베이스는 신뢰할 수 있는 데이터 소스로 간주되며 슬레이브 데이터베이스는 마스터 데이터베이스와 동기화됨. 컴퓨터 시스템에서 버스와 연결된 주변 장치.
4. 파이프 - 필터 패턴 : 데이터 스트림을 생성하고 처리하는 시스템에서 사용할 수 있음. 각 처리 과정은 필터 컴포넌트에서 이루어지며, 처리되는 데이터는 파이프를 통해 흐름. 이 파이프는 버퍼링 또는 동기화 목적으로 사용될 수 있음.
활용 사례 : 컴파일러, 연속한 필터들은 어휘 분석, 파싱, 의미 분석 그리고 코드 생성을 수행함
5. 브로커 패턴 : 분리된 컴포넌트들로 이루어진 분산 시스템에서 사용. 이 컴포넌트들은 원격 서비스 실행을 통해 서로 상호 작용을 할 수 있음. 브로커 컴포넌트는 컴포넌트 간의 통신을 조정하는 역할을 하며, 서버는 자신의 기능들을 브로커에 넘겨주고, 클라이언트가 브로커에 서비스를 요청하면 브로커는 클라이언트를 자신의 레지스트리에 있는 적합한 서비스로 리디렉션함.
활용 사례 : Apache ActiveMQ, Apache Kafka, RabbitMQ 및 JBoss Messaging 과 같은 메시지 브로커 소프트웨어
6. 피어 투 피어 패턴 : 각 컴포넌트를 피어라고 부름. 피어는 클라이언트로서 피어에게 서비스를 요청할 수도 있고, 서버로서 각 피어에게 서비스를 제공할 수도 있음. 피어는 클라이언트 또는 서버 혹은 둘 모두로서 동작할 수 있으며, 시간이 지남에 따라 역할이 유동적으로 바뀔수 있음.
활용 사례 : Gnutella나 G2와 같은 파일 공유 네트워크, P2PTV나 PDTP와 같은 멀티미디어 프로토콜, Spotify와 같은 독점적 멀티미디어 애플리케이션
7. 이벤트 - 버스 패턴 : 주로 이벤트를 처리하며 이벤트 소스, 이벤트 리스너, 채널 그리고 이벤트 버스의 4가지 주요 컴포넌트들을 가짐. 소스는 이벤트 버스를 통해 특정 채널로 메시지를 발행하며, 리스너는 특정 채널에서 메시지를 구독함. 리스너는 이전에 구독한 채널에 발행된 메시지에 대해 알림을 받음.
활용 사례 : 안드로이드 개발, 알림 서비스
8. 모델 - 뷰 - 컨트롤러 패턴 : MVC 패턴이라고도 하는 이 패턴은 대화형 애플리케이션으로 다음의 세 부분으로 나눠짐. 모델은 핵심 기능과 데이터를 포함함. 뷰는 사용자에게 정보를 표시하며, 컨트롤러는 사용자로부터의 입력을 처리함. 이는 정보가 사용자에게 제공되는 방식과 사용자로부터 받아들여지는 방식에서 정보의 내부적인 표현을 분리하기 위해 나뉘며, 이는 컴포넌트를 분리하며 코드의 효율적인 재사용을 가능하게 함.
활용 사례 : 일반적인 웹 애플리케이션 설계 아키텍처, Django나 Rails와 같은 웹 프레임워크
● SW 아키텍처 4+1 View
| 사용사례관점(Use Case View) | 시스템의 외부 사용자 관점에서 사용 사례들 간의 관계를 정의 |
| 논리관점(Logical View) | 상위 수준에서 시스템의 논리적인 구조/행위를 클래스 인터페이스, 협력관계로 정의 |
| 구현관점(Implementation View) | 독립적으로 실행되는 컴포넌트와 이들 간 관계를 정의 |
| 프로세스관점(Process View) | 시스템의 병렬처리 및 동기화 처리를 위한 스레드와 프로세스 정의 |
| 배치관점(Deployment View) | 실행되는 시스템 하드웨어와 소프트웨어 관계를 정의 |
● 다형성 오버로딩과 오버라이딩
| 구분 | 오버로딩(Overloading) | 오버라이딩(Overriding) |
| 개념 | 하나의 클래스 내에서 같은 이름으로 여러 개의 메서드를 정의 | 상속관계인 상위 클래스의 메서드를 하위클래스에서 재정의 |
| 메서드명 | 특정 클래스 내 동일 | 상속관계 내 동일 |
| 매개변수개수, 타입 | 개수 또는 타입이 다름 | 반드시 동일 |
| 리턴 타입 | 상관없음 | 기본적으로 동일 |
| 접근제한 | 상관없음 | 범위가 같거나 넓어야 함 |
● 디자인 패턴의 분류
| 목적 | 생성 패턴(Creation Pattern) | 구조 패턴(Structural Pattern) | 행위 패턴(Behavioral Pattern) | |
| 의미 | 객체의 생성방식을 결정하는 패턴 | 객체를 조직화하는데 유용한 패턴 | 객체의 행위를 조직, 관리, 연합하는데 사용하는 패턴 | |
| 범위 | 클래스 | Factory method | Adapter | Template method Interpreter |
| 객체 | Singleton Abstract factory Builder Prototype |
Bridge Composite Decorator Facade Fly weight Proxy |
Iterator Command Chain of Responsibility State Strategy Mediator Memento Visitor Observer |
|
● Fan-In Fan-Out
소프트웨어 설계의 올바른 지침으로 적당한 모듈의 크기 유지, 모듈 응집력은 높게, 모듈 결합도는 낮게, 모듈간의 접속 관계를 분석하여 복잡도와 중복을 줄이고, 모듈의 복잡도 및 효과적인 제어를 위해 계층적 자료 조직과 관련하여 Fan-In은 높게, Fan-Out은 낮게 작성하는것이 좋음.
Fan-In (공유도) = 어떤 모듈을 제어(호출)하는 모듈의 수, 하나의 모듈이 제어 받는 상위 모듈의 수
Fan-Out (제어폭) = 어떤 모듈에 의해 제어(호출)되는 모듈의 수, 하나의 모듈이 제어하는 하위 모듈의 수
● 요구사항 검증 방법
| 동료 검토 (PeerReview) | 2~3명이 진행하는 리뷰의 형태 요구사항 명세서 작성자가 요구 사항 명세서를 설명하고 이해관계자들이 설명을 들으면서 결함을 발견하는 형태로 진행 |
| 워크 스루 (Walk Through) | 소프트웨어 시스템 개발 단계마다 실시하는 비정형 검토 회의 오류를 조기에 검출하는데 목적을 두고 리뷰를 통해 오류를 검출하고 문서화함 |
| 인스펙션 (Inspection) | 소프트웨어 요구, 설계, 원시 코드 등의 저작자 외의 다른 전문가 또는 팀이 검사하여 오류를 찾아내는 공식적 검토 방법 소프트웨어의 품질을 높이는 방법 중 하나 |
● CASE (Computer Aided Software Engineering)
CASE = 계획 수립에서부터 요구분석, 설계, 개발, 유지보수에 이르는 소프트웨어 생명주기 전 과정을 자동화 할 수 있도록 지원하는 자동화 도구
- 컴퓨터 지원 시스템 공학이라고도 함
- 개발자의 반복적인 작업량을 줄이도록 하기 위해 사용
- CASE 도구들은 문서의 생성과 개발팀 간의 협업을 도움. 작업된 내용을 검토하고 수정하기 위해 서로 다른 사람의 파일에 접근하도록 허용해 팀 구성원들은 그들의 작업을 손쉽게 공유할 수 있음
| Upper CASE | 계획 수립, 요구분석, 기본설계 단계를 지원하고 이를 다이어그램으로 표현 |
| Middle CASE | 상세설계 작업을 지원하며 화면/출력 등의 작성을 지원 |
| Lower CASE | 시험, 유지보수 작업 지원하며 소스코드와 시스템 명세서를 획득 |
| I-CASE | 위 세가지를 통합한 것으로 Rational ROSE, COOL 등이 국내에서 사용 중 |
● 내외부 송수신 연계
내외부 송수신의 연계 방식은 직접 연계 방식과 간접 연계 방식으로 분류
직접 연계 방식 = 중계서버나 솔루션을 사용하지 않고 송신 시스템과 수신 시스템이 직접 인터페이스 하는 방식
간접 연계 방식 = 연계 솔루션에서 제공하는 송수신 엔진과 어댑터를 활용하는 인터페이스 방식
● 연계 프로그램 기술
| DB Link | 데이터베이스에서 제공하는 DB Link 객체를 활용한 연계 기술 |
| DB Connection | 송신 시스템 DB로 연결하는 DB Connection Pool을 생성하고 연계 프로그램에서 해당 DB Connection Pool을 이용하는 기술 이외 API/OpenAPI, JDBC, Hyper Link 등의 연계 기술이 있음 |
| Socket | 통신을 위한 프로그램으로 포트를 할당하고 클라이언트의 통신 요청시 클라이언트와 연결하는 연계 기술 |
| Web Service | WSDL, UDDI, SOAP 프로토콜을 이용하여 연계하는 연계 기술 |
● 인터페이스 보안 코딩
1. 인터페이스 보안 기능
| 민감정보가상화 | 인터페이스 데이터 중 민간정보(전화번호, 주민번호 등)는 비식별화 조치 |
| 인증 보안 수행 | 인터페이스 수행에 필요한 인증 수행(보안 토큰 소유 확인) |
| 이상 거래 감지 | 외부 불법 접근 시도, 무작위 공격 행위 탐지 기능 |
| 피드 암/복호화 | 정의된 보안 필드를 인터페이스하기 전 암/복호화 |
| 필드 필터링 | 필드 필터링을 통해 필수 정보만을 제공 |
| 암호화 키 전송 | UI에 Field 암호화, Hash를 위한 암호화 Key를 반환하는 기능 |
| 파일 암/복호화 | 파일 서버에 저장된 파일을 암/복호화하는 기능 |
| 체크섬 | 송/수신 시스템 간 체크섬 검증하여 메시지 위변조 확인 |
- 암호화 알고리즘은 DES보다는 AES 알고리즘을 적용
2. 중요 인터페이스 데이터 암호화 저장
- 개인정보, 금융정보, 패스워드 등 암호화
3. 중요 인터페이스 데이터 암호화 전송
- 민감한 정보를 통신 채널을 통하여 내보낼 때는 반드시 암호화 과정을 거쳐야 하며, 필요한 경우 SSL 또는 HTTPS 등과 같은 보안 채널을 사용
● 인터페이스 처리 유형
| 동기(Sync) 거래 | 요청 서비스에서 응답메시지를 즉시 받아 처리하는 거래 |
| 비동기(Async) 거래 | 요청 결과 수신서비스에서 응답 메시지를 대신 받아 처리 |
| 지연(Deferred) 거래 | 메시지를 수신 시스템에 일정시간 간격을 두고 반영하는 거래 |
| 파일(File) 거래 | 송수 파일을 수신 시스템에서 Batch 처리로 반영하는 거래 |
● 미들웨어 솔루션 유형
미들웨어 = 기능적으로 클라이언트와 서버 사이의 통신을 담당하는 시스템 소프트웨어로 컴퓨터와 컴퓨터의 연결을 담당하는 소프트웨어로 중간을 의미하는 Middle과 Software를 의미하는 Ware의 합성어
| RPC (Remote Procedure Call) | 응용 프로그램의 프로시저를 사용하여 원격 프로시저를 로컬 프로시저처럼 호출하는 방식의 미들웨어 |
| MOM (Message Oriented Middleware) | 메시지 기반의 비동기형 메시지 전달 방식 미들웨어로 서로 다른 이기종 분산 데이터 시스템의 데이터 동기를 위하여 주로 사용 |
| ORB (Object Request Broker) | 코바(CORBA) 표준 스펙을 구현한 객체지향 미들웨어 |
| WAS (Web Application Server) | 웹 환경을 구현하기 위한 미들웨어, 기능은 자바, EJB 컴포넌트 기반으로 구현 가능 |
| TP - 모니터 | 온라인 업무에서 트랜잭션을 처리, 감시하는 미들웨어로 사용자 수가 증가하여도 빠른 응답 속도를 유지해야 하는 업무에 적합 |
● 웹 서버
웹 서버 = 웹 브라우저의 요청을 받아 html 파일이나 이미지/그림, 자바스크립트의 정적인 콘텐츠 제공
웹 애플리케이션 서버(WAS) = 서버계층에서 애플리케이션이 동작할 수 있는 환경을 제공하고 안정적인 트랜잭션 처리와 관리, 다른 이기종 시스템과의 애플리케이션 연동을 지원. 웹서버와의 가장 큰 차이점은 동적 서버 콘텐츠를 수행할 수 있는 기능.
● 클래스 다이어그램의 다중성(multiplicity)
| 1 | 엄밀하게 1 |
| * | 0 또는 그 이상 |
| 0..* | 0 또는 그 이상 |
| 1..* | 1 이상 |
| 1..5 | 1 ~ 5 사이의 값 |
| 1,3,5 | 1 또는 3 또는 5 |
댓글