.gif&blockId=11b00c82-b138-8050-a58b-dcbceda2ef8f)
목차
소프트웨어
소프트웨어의 특징
•
상품성 : 소프트웨어를 개발하면 상품이 되어 판매가 됨.
•
복잡성 : 개발 과정이 복잡하고 관리가 어려움.
•
변경 가능성 : 프로그램을 일부 수정하여 업그레이드 및 오류 수정 등 가능.
•
복제성 : 복제가 용이해 쉽게 복사, 유통이 가능함.
시스템
•
기본 요소
◦
입력, 처리, 출력, 제어, 피드백
소프트웨어 위기의 원인
•
하드웨어 비용을 초과하는 개발 비용의 증가
•
개발 기간의 지연
•
개발 인력 부족 및 인건비 상승
•
성능 및 신뢰성 부족
•
유지보수의 어려움에 따른 엄청난 비용
소프트웨어 공학의 기본 원칙
•
현대적인 프로그래밍 기술을 적용해야 함.
•
신뢰성이 높아야 함.
•
사용의 편리성과 유지보수성이 높아야 함.
•
지속적인 검증 시행을 해야 함.
소프트웨어 재공학
•
장점
◦
개발 시간 및 비용 감수
◦
품질 향상
◦
생산성 향상
◦
신뢰성 향상
◦
구축 방법에 대한 지식의 공유
◦
프로젝트 실패 위험 감소
•
목표
◦
소프트웨어의 유지보수성 향상
◦
복잡한 시스템을 다루는 방법 구현
◦
다른 뷰의 생성
◦
잃어버린 정보의 복구 및 제거
◦
재사용을 수월하게 하며 소프웨어의 수명 연장
•
과정
분석(Analysis) → 구성(Restructuring) → 역공학(Re-verse Engineering) → 이식(Migration)
유지 보수 유형
•
수정(Corrective Maintenance) : 오류를 수정
•
적응(Adaptive Maintenance) : 외부 환경의 변화에 적응하기 위한 수정
•
완전(Perfective Maintenance) : 기능이나 성능 향상을 위해 수정
•
예방(Preventive Maintenance) : 이해성과 유지보수성의 개선을 위한 수정 : 재공학
역공학
•
다시 쓰기 위한 거
•
소프트웨어를 분석하여 소프트웨어 개발 과정과 데이터 처리 과정을 설명하는 분석 및 설계 정보를 재발견하거나 다시 만들어내는 과정
•
재문서화
CASE
•
소프트 엔지니어링을 도와주는 자동화 도구
CASE가 제공하는 기능
•
개발 신속, 오류 수정 쉬워 소프트웨어 품질 향상
•
소프트웨어 생명주기의 전체 단계 연결 - 자동화시켜 주는 통합된 도구 제공 기술
•
소프트웨어 시스템의 문서화 및 명세화를 위한 그래픽 기능 제공
•
소프트웨어 개발 단계의 표준화 기할 수 있으며 자료 흐름도 작성 기능 제공
•
모델들 사이의 모순 검사 기능을 제공하며 다양한 소프트웨어 개발 모형 지원
•
원천 기술 : 구조적 기법, 프로토타이핑 기술, 정보 저장소 기술
CASE 장점
•
소프트웨어 개발 비용 절약 → 소프트웨어 생산성 향상
•
품질 향상
•
유지보수 간편, 재사용성 향상98
CASE 분류
•
상위(Upper) CASE : 요구 분석, 설계 단계 지원
•
하위(Lower) CASE : 소스 코드 작성, 테스트, 문서화 과정 지원
•
통합(Integrate) CASE : 소프트웨어 개발 주기 전체 과정 지원
요구사항 분석을 위한 CASE 도구
•
SADT : SoftTech사 - 블록 다이어그램을 채택한 자동화 도구
•
REM : TRW사
◦
RSL : 요구사항 기술 언어
◦
REVS : 요구사항 분석기
•
PSI / PSA
•
TAGS
소프트웨어 개발 방론
소프트웨어 생명주기(Life Cycle)
•
타당성 검토 → 개발 계획 → 요구사항 분석 → 설계 → 구현 → 테스트 → 운용 → 유지보수
폭포수 모형(Waterfall Model)
•
소규모 프로젝트에 적합
•
고전
나선형 모형(Spiral Model)
•
계획 수립 → 위험 분석 → 개발 및 검증 → 고객 평가
하향식과 상향식 설계
•
하향식 설계 : 뿌리부터 시작하여 하위 기능들로 나눠 가면서 설계하는 방식
•
상향식 설계 : 기본 컴포넌트를 먼저 설계한 다음 이것을 사용하는 상위 수준 컴포넌트 설계 방식
프로토타입 모형
•
실제 개발될 시스템의 견본(Prototype)을 미리 만들어 최종 결과물을 예측하는 모형
HIPO(Hierarchy Input Process Output)
•
계층적 입력 처리 출력
•
폭포수 모델과 비슷함.
•
하향식 소프트웨어 개발을 위한 문서화 도구
•
총체적(Overview Diagram), 세부적 다이어그램(Detail Diagram)으로 구성
•
가시적 도표를 사용 - 보기 쉽고 이해하기 쉬우며 유지보수 쉽다.
V-모델
•
폭포수 모형에 시스템 검증과 테스트 작업을 강조한 모델
•
HIPO에 테스트를 추가한 모델
에자일(Agile) 개발 방법론
•
고객과의 협업에 초점 두고 개발하는 방법론
•
목표대로 만들어졌느냐 만 중요 - 결과
•
종류
익스트림프로그램, 린, DSDM, FDD, Crystal, ASD, DAD
에자일 선언문
•
고객하고 제대로 소통해서 고객이 원하는 거 만들어주는 것
XP
•
빠르게 양질의 소프트웨어를 만드는 것
•
핵심 가치
◦
소통(Communication)
◦
단순성(Simplicity) : 배제
◦
Feedback
◦
용기(Courage)
◦
존중(Respect)
XP Process
•
User Story
◦
Spike : 요구사항, 잠재적 솔루션을 고려하기 위해 작성하는 간단한 프로그램
◦
User Stories : 사용자 요구사항을 간단한 시나리오로 표현
•
Release Planning : 부분 기능 완료 제품 제공
•
Iteration : 새로운 요구사항 삽입 단계
•
Acceptance Test : 테스트 단계
•
Small Realease : 실제 수행 단계
XP 12가지 실천사항
•
FIne Scale Feed-back
◦
Pair Program-ming (짝 프로그래밍)
◦
Planning Game
◦
Test Driven Develop-ment
◦
Whole Team
•
Continuous Process
◦
Continuous Integration
◦
Design Imporvement
◦
Small Releases
•
Shared Understand-ing
◦
Coding Standards
◦
Collective Code Ownership
◦
Simple Design
◦
System Metaphor
•
Programmer Welfare
◦
Sustainable Pace
효과적인 프로젝트 관리 3대 요소 3P
•
사람 - 인적 자원
•
문제 - 문제 인식
•
프로세스 - 작업 계획
SCRUM
•
요구사항 파악 빠르게 개발
•
스프린트 반복 주기 2~4주
•
기본 원리
◦
스프린트 단위 개발
◦
30일 반복 - 고정
◦
잘 드러나야 함
◦
시간을 지켜져야하며 Product 백로그에 기록
◦
일일 스크럼
•
팀 역할
◦
제품 책임자
▪
기능 목록 작성
▪
우선순위 갱신
▪
신규 항목 추가
▪
스프린트 임무 수행
▪
이후 팀 운영 관여 X
◦
스크럼 마스터
▪
업무 배분만 함
▪
소멸 차트에 기록
▪
개발 과정에서 지원
◦
스크럼 팀
▪
5~9명 구성
▪
작업 단위로 기능 분류
▪
요구사항 사용자 스토리 도출, 구현
▪
일정 속도를 추정한 뒤 제품 책임자에게 전달, 시연
▪
매일 진행상황 점검
현행 시스템 분석
현행 시스템
1.
1단계(시스템 구성 파악 - 시스템 기능 파악 - 시스템 인터페이스 현황 파악)
어떻게 운영되고 있는지
2.
2단계(아키텍처 파악 - 소프트웨어 구성 파악)
3.
3단계(시스템 하드웨어 현황 파악 - 네트워크 구성 파악)
시스템 아키텍처
•
시스템의 전체 구조, 행위, 행위 원리를 나타내며, 시스템이 어떻게 작동하는지 설명하는 틀
•
시스템 내의 상위 시스템과 하위 시스템이 상호 작용하는지에 대한 동작 원리와 구성을 표현한 것
•
시스템 아키텍처 
소프트웨어 아키텍처 → 소프트웨어 상세 설계
소프트웨어 아키텍처 → 소프트웨어 상세 설계시스템 구성 파악
•
기간 업무(핵심)와 지원 업무(따로) 구분 - 문서화
시스템 기능 파악
•
각각의 기능을 구분하여 계층형으로 표시
인터페이스 현황 파악
•
단위 업무 시스템이 타 단위 업무 시스템과의 연계 명시
EAI(기업 애플리케이션 통합)
•
다양한 소프트웨어 통합 계획, 방법 및 도구
FEP(전위 처리기)
•
전 처리기
•
시간을 줄여주는 프로그램
소프트웨어 구성 파악
•
라이선스 수량 파악 중요
하드웨어 구성 파악
•
컴퓨터 사양
플랫폼
•
기반 시설
•
소프트웨어를 만들기 위한 기반
•
특성 분석 항목
◦
응답 시간(Response Time)
◦
가용성(Availablility)
◦
사용률(Utilization)
•
성능 특성 분석 방법
◦
기능 테스트
◦
사용자 인터뷰
◦
문서 점검
현행 시스템의 OS
•
분석 항목 : 현재 정보 시스템의 OS 종류와 버전, 패치 일자, 백업 주기 분석
•
고려 사항 : 가용성, 성능, 기술 지원, 주변기기, 구축 비용(TCO - 총비용)
•
메모리 누수
오픈소스 라이선스 종류
•
GNU : Linux
•
GNU GPLv1 : 소스 코드 공개 X, 바이너리만 배포 금지
•
BSD : 공개 하지 않아도 되는 상용 소프트웨어에서도 사용 가능
•
Apache 2.0 : HADOOP - 대량 데이터 처리 기술
DBMS
•
종속성과 중복성의 문제 해결하기 위해 제안된 시스템
•
분석 시 고려사항
◦
가용성
◦
성능
◦
기술 지원
◦
상호 호환성
◦
구축 비용
요구사항 개발
요구공학(Requirements Engineering)
•
자료 흐름도, 자료 사전 - 소단위 명세서 활용
•
소프트웨어 개발 시 사용자의 요구를 정확히 반영한 시스템 개발을 위한 구조화된 활동 집합
•
목적
◦
의사소통 수단 제공
◦
누락 방지, 상호 이해 오류 등의 제거로 경제성 제공
◦
개발 비용 및 시간 절약
◦
비용과 일정에 대한 제약 설정과 타당성 조사, 요구사항 정의 문서화 등 수행
•
베이스라인(기준선)
•
요구공학(개발) 프로세스
SWEBOK(소프트웨어 공학 지식 체계)에 따른 요구사항 개발 프로세스
요구사항 도출(추출)
•
도출 기법 : 고객 발표, 문서 조사, 설문, 업무 절차 및 양식 조사, 브레인스토밍, 워크숍, 프로토타이핑, 인터뷰, BPR, RFP
요구사항 분석
•
요구 분석을 위한 기법
◦
사용자 의견 청취
◦
각종 문서 분석과 중재
◦
관찰 및 모델 작성 기술
◦
설문 조사를 통한 의견 수렴
•
요구사항 분석 수행 단게
◦
문제 인식
◦
전개
◦
평가와 종합
◦
검토
◦
문서화
요구사항 분류
•
기술 내용에 따른 분류 : 기능/비기능 요구사항
◦
기능적 : 실제로 어떻게 동작하는지 관점
◦
비기능적 : 성능, 보안, 품질, 안정성 등 보조적
•
기술 관점 및 대상에 따른 분류 : 시스템/사용자 요구사항
•
요구사항 분류 기준
◦
구분 후 우선순위 여부 확인
•
요구사항 명세
◦
명세 기법
▪
정형 명세
•
기법 : 수학적/모델링
•
종류 : Z, VDM, Petri-Net, LOTOS, CSP, CCS
•
장점 : 시스템 요구 특성 적확하고 명세가 간결하게 명세할 수 있음.
•
단점 : 낮은 이해도, 이해관계자의 부담 가중
▪
비정형 명세
•
기법 : 상태/기능/객체 중심 명세, 자연어
•
종류 : FSM, Decision Table, ER, State Chart(SADT), UseCase, 사용자 기반
•
장점 : 명세 작성 이해 용이, 의사전달 방법 다양성
•
단점 : 불충분한 명세 기능, 모호성
◦
명세 속성
▪
정확성
▪
명확성
▪
완전성
▪
일관성
▪
수정 용이성
▪
추적성
요구사항 확인
•
형상 관리
◦
형상 단위 : 애플리케이션 개발 단계에서 도출되는 프로그램, 문서, 데이터 등의 모든 자료
◦
모든 자료의 변경을 관리함으로써 애플리케이션 버전 관리 등을 하는 활동
•
완전한지 검증
•
요구사항 관리 도구 필요성
◦
비용 편익 분석, 요구사항 변경의 추적/영향평가
요구사항 할당
정형 분석
•
오해 최소화, 마지막 단계
요구사항 확인 기법
•
프로토타이핑
◦
추가 요구사항 지속 재작성 과정
◦
절차
1.
요구사항 분석 단계
2.
프로토타입 설계 단계
3.
프로토타입 개발 단계
4.
고객 평가 단계
5.
프로토타입 정제 단계
6.
완제품 생산 단계
◦
품질 저하, 비용 발생, 빠르게 제작 가능, 유용한 피드백 제공
•
모델 검증
◦
정적 분석 : 검증을 위한 분석 도구
◦
동적 분석 : 직접 실행
•
요구사항 검토
•
인수 테스트
◦
확인 단계
◦
종류 : 계약 인수 테스트, 규정 인수 테스트, 알파 검사, 베타검사, 사용자 인수 테스트, 운영 인수 테스트
UML
개념 모델링
•
요구 사항을 이해하기 쉽도록 실 세계의 상황을 단순화하여 개념적으로 표현한 것(모델)을 생성해 나가는 과정
•
종류 : Use Case Diagram, Data flow Model, State Model, Goal-Based Model, User Interactions, Object Model, Data Model
UML
•
범용 모델링 언어
•
럼바우를 사용
럼바우 객체지향 분석 기법
1.
객체 모델링(OMT)
•
== 정보 모델링
•
정적 구조 생성
•
객체 다이어그램
2.
동적 모델링
•
상태 다이어그램
3.
기능 모델링
•
자료 흐름도
UML 특성
•
비주얼화
◦
소프트웨어 구성 요소 간의 관계 및 상호작용 시각화
•
문서화
◦
소프트웨어 생명주기의 중요한 작업을 추적하고 문서화
•
명세화
◦
단순 표기법이 아닌 구현에 필요한 개발적 요소 및 기능에 대한 명세 제공
•
구축
◦
객체지향 언어로 매핑될 수 있다.
UML 관점
•
기능적 관점
◦
사용자 측면에서 본 소프트웨어 기능 - 사용 사례 모델링
◦
Use Case Diagram
•
정적 관점
◦
소프트웨어 내부의 구성요소 사이의 구조적 관계
◦
Class Diagram
•
동적 관점
◦
시스템의 내부 동작
◦
Sequences/State/Activity Diagram
UML 기본 구성
•
사물
◦
객체지향 모델 구성 기본 요소
◦
객체 간의 관계 형성 대상
•
관계
◦
객체 간의 연관성 표현
•
다이어그램
◦
객체의 관계 도식화
◦
View 제공
스테레오 타입
•
스테레오 타입 객체 표현 사용 기호 : 길러멧(Guilemet) <<>>
UML 접근 제어자
•
Public +
•
Private -
•
Protected #
•
Package ~
연관 관계 다중성 표현
•
1 : 1 개체 연결
•
* or 0..* : 0이거나 그 이상 객체 연결
•
1..* : 1이거나 1이상 객체 여
•
0..1 : 0이거나 1 객체 연결
•
1, 3, 6 : 1이거나 3이거나 6 객체 연결
•
n : n개 객체 연결
•
n..* : n이거나 n개 이상 객체 연
UML 다이어그램의 분류
•
구조적(Structural) 다이어그램
◦
정적, 구조 표현을 위한 다이어그램
▪
클래스(Class) 다이어그램 : 정적 구조 표현
▪
객체(Object) 다이어그램
▪
복합체 구조(Composite Structure) 다이어그램
▪
배치(Deployment) 다이어그램 : 물리 구조
▪
컴포넌트 다이어그램
▪
패키지 다이어그램
•
행위 다이어그램
◦
동적 표현을 위한 다이어그램
▪
유스케이스 다이어그램 : 사용자 관점
▪
활동 다이어 그램 : 업무 처리, 연산 수행
▪
상태 머신 다이어그램 : 생명주기
▪
콜라보레이션 다이어그램
▪
상호작용 다이어그램
•
순차(Sequence Diagram) 다이어그램
생명선, 통로, 상호작용, 발생, 실행, 상태 불변, 상호작용, 메시지, 활성, 객체, Actor
•
상호작용 개요 다이어그램
•
통신 다이어그램 : 관계
•
타이밍 다이어그램 : 시간 제약
클래스 다이어그램
•
객체 간의 관계 추상화 모델을 논리적 구조 표현
UML 관계 표현
•
단방향 연관 관계 : →
•
양방향 연관 관계 : —
•
의존 관계 : - - →
•
일반화 관계 : —(상속 관계)
(상속 관계)•
집합/포함 관계 : —◆ (클래스 사이 전체나 부분이 같은)
: —◇
•
실체화 관계 : - - -
UML 관계
•
연관 : 관련
•
의존 : 필요
•
일반화 : 상속
•
집합 : 전체-부분
•
포함
•
실체화
Use Case Diagram
•
요소
◦
시스템 경계(Boundary)
◦
액터(Actor)
◦
유스케이스(Use Case)
◦
접속 관계(communication Association)
◦
사용 관계(Uses Association)
◦
확장 관계(Extends Association)
•
작성 단계
1.
액터식별
2.
Use Case 식별
3.
관계 정의
4.
Use Case 구조
소프트웨어 아키텍처
ISO/IEC 9126 모델
•
소프트웨어 품질 특성과 평가를 위한 국제 표준
•
내외부 품질 : 기능성(Functionality), 신뢰성(Reliability), 사용성(Usability), 효율성(Efficiency), 유지보수성, 이식성
•
사용 품질 : 효과성, 생산성, 안전성, 만족도
•
외부지표
•
내부지표
ISO/IEC 25010
UI 표준을 위한 환경 분석
•
사용자 경향 분석
◦
기존/현존 UI 경향 숙지 - 현재 UI 단점 작성
◦
사용자 요구사항 파악, 쉽게 이해 가능한 기능 위주로 기술 영역을 정의
•
기능 및 설계 분석
◦
기능 조작성 분석
◦
오류방지 분석
◦
최소한 조작으로 업무 처리 가능한 형태 분석
◦
UI 정보 전달력 확인
•
요구사항 요소
◦
데이터 요구
◦
기능 요구
◦
제품, 서비스 품질
◦
제약 사항
정황 시나리오 작성
•
개발하는 서비스 초기 모양 상상 단계
•
사용자 관점
•
낙관적 상황
•
육하원칙
•
간단명료, 하나의 시나리오 통합
UI 표준 및 지침
UI 분야
•
표현
•
정보 제공, 전달
•
기능
특징
•
만족도 직접 영향
•
편리, 가독, 동선의 축약
UI 개발 시스템이 가져야 할 기능
•
사용자 입력의 검증
•
에러 처리, 에러 메시지 처리
•
도움과 프롬프트 제공
UI 설계
•
설계 원칙
◦
직관성 : 누구나 쉽게 이해하고 사용할 수 있도록
◦
유효성 : 유용하고 효과적
◦
학습성 : 쉽게 배우고 익히게
◦
유연성 : 오류 최소화
•
설계 지침
◦
사용자 중심
◦
일관성
◦
단순성
◦
가시성
◦
표준화
◦
접근성
◦
결과 예측 가능
◦
명확성
◦
오류 발생 해결
UI 표준
•
최소한의 요소 및 배치 규칙 등을 의미
•
한국형 웹 콘텐츠 접근성 지침 2.1 4가지 원칙
◦
인식의 용이성
◦
운용의 용이성
◦
이해의 용이성
◦
견고성
UX(사용자 경험)
•
사용자가 제품을 대상으로 직/간접적으로 사용하면서 느끼고 생각하게 되는 지각과 반응, 행동 등의 모든 경험
•
영향을 주는 요소 : 성능, 시간
•
모바일 사용자 설계 고려사항
◦
대상, 환경, 목적, 빈도 등 고려
◦
직관적 파악 가능
◦
입력 최소화, 자동 완성 기능
◦
되돌림 기능 제공
◦
모바일 서비스 특성에 적합한 디자인 제공
UI 설계
UI 설계 단계
•
문제 정의
•
사용자 모델 정의
•
작업 분석
•
컴퓨터 오브젝트 및 기능 정의
•
사용자 인터페이스 정의
•
디자인 평가 : 평가 방법론
◦
GOMS : 인간이 어떤 행위를 할지 예측하여 문제를 해결하는 데 필요한 소요 시간, 학습 시간 등을 평가하기 위한 기법
◦
Heuristics : 논리적 근거가 아닌 어림짐작을 통해 답을 도출해 내는 방법
UI 상세 설계 단계
1.
UI 메뉴 구조 설계
2.
내/외부 화면과 폼 설계
3.
UI 검토 수행
UI 상세 설계 - 시나리오 작성 원칙
•
구체적 작성
•
Flowchart 표기법
•
UI요소, 상호작용(Interaction)을 일반적인 규칙 정의
•
상호작용의 흐름 및 순서, 분기, 조건, 루프를 명시
•
예외 상황에 관한 사례 정의, UI 시나리오 규칙 지정
•
기능별 상세 기능 시나리오 정의, UI 일반 규칙 지킴
•
시나리오 문서의 작성 요건
완전성, 일관성, 이해성, 가독성, 수정 용이성, 추적 용이성
UI 요구사항 정의
•
시스템 구조
•
사이트맵
•
프로세스 정의
•
화면 설계
UI 설계 도움 주는 도구들
•
와이어 프레임(Wire Frame)
◦
파워포인트, 키노트, Sketch, Balsamiq, 카카오 오븐
•
목업(Mockup) > 와이어 프레임
◦
카카오 오븐, Power Mockup, Balsamiq
•
프로토타입(Prototype) > 목업
◦
상호작용
•
스토리보드(Storyboard)
◦
사용자, 작업, 인터페이스 간 상호작용 시각화
UI 프로토타입
•
도출된 요구사항을 토대로 프로토타입(시제품)을 제작하여 대상 시스템과 비교하면서 개발 중에 도출되는 추가 요구사항을 지속해서 재작성하는 과정
감성 공학 접근 방법
•
1류(의미 미분법) : 인간 감각, 감성
•
2류 : 1류의 기본틀, 감성 어휘 수집 전단계에서 평가자들의 생활 양식 추가
•
3류 : 1류의 감성 어휘 대신 감각 척도로 감성 표
HCI
•
인간과 컴퓨터의 상호작용
감성 공학 요소 기술
•
기초, 구현, 응용
소프트웨어 설계
소프트웨어 설계 모델링
•
최종 제작할 소프트웨어의 청사진을 만드는 것
설계 기본 원리
•
분할과 정복, 추상화, 단계적 분해, 모듈화, 정보 은닉
소프트웨어 설계 분류
•
상위 설계 : 아키텍처 설계 - 데이터 설계 - 인터페이스 정의 - 사용자 인터페이스 설계
•
하위 설계 : 모듈 설계 - 자료구조 설계 - 알고리즘 설계
◦
하위 설계 방법
▪
절차 기반(Procedure-Oriented)
▪
자료 위주(Data-Oriented)
▪
객체 지향(Object-Oriented)
소프트웨어 설계 대상
•
구조 모델링
◦
기능적 관점
◦
정적
•
행위 모델링
◦
상호작용
◦
동적
소프트웨어 설계 방법
•
구조적 설계
◦
Coad/Yourdon
•
자료 중심 설계
◦
Jackson Warner-Orr
•
객체지향 설계
◦
Yourdon, Sheller/Meller, Rumbaugh, Boach
소프트웨어 구조도
•
Fan-in : 상위 모듈 수
•
Fan-out : 하위 모듈 수
•
Depth : 깊이
•
Width : 같은 등급
•
Super ordinate : 다른 모듈 제어
•
Sub ordinate : 제어 당하는 모듈
•
Fan-in이 높은 경우
◦
재사용 측면에서 잘된 설계
◦
단일 장애 발생을 방지하기 위해 중점 관리 필요
◦
단일 장애 발생 가능성 있음.
•
Fan-out이 높은 경우
◦
불필요한 타 모듈 호출 여부 확인
◦
단순 설계 가능 여부 검토
•
복잡도 최적화를 위한 조건
◦
Fan-in을 높이고 Fan-out은 낮추도록 설계
코드 설계
•
코드 : 데이터의 사용 목적에 따라 식별하고 분류, 배열하기 위해 사용하는 숫자, 문자 혹은 기호
•
코드 설계 순서
1.
코드 대상 선정
2.
코드화 목적 명확화
3.
코드 부여 대상 수 확인
4.
사용 범위 결정
5.
사용 기간 결정
6.
코드화 대상의 특성 분석
7.
코드 부여 방식 결정
8.
코드의 문서화
•
코드의 기능
◦
기본적 기능
▪
표준화 기능
▪
간소화 기능
◦
3대 기능
▪
분류 기능
▪
식별 기능
▪
배열 기능
◦
부가적 기능
▪
연상 기능
▪
암호화 기능
▪
오류 검출 기능
•
코드 설계 목적 및 특성
◦
고유성
◦
분류 편리성
◦
배열의 효율성
◦
간결성
◦
유지보수 편리성
◦
코드의 독립성
◦
코드의 편의성
◦
추가/삭제 편리성
코드의 종류
•
순차(Sequence) 코드
◦
확장성 좋고, 단순, 기억 쉬움.
◦
항목 수 적고, 변경 적은 자료 적합, 기억 공간 낭비 적음.
◦
웅통성 낮음.
•
블록 코드
◦
기계 처리 어려움. 여유 코드는 코드 낭비 요인
•
그룹 분류식 코드
◦
여유 부분이 있어 자료 추가 쉽게 처리 가능 but 자릿수 길어질 수 있음.
•
10진 분류 코드
◦
도서 분류 코드 사용
•
표의 숫자 코드
◦
의미가 있는 코드(수치있음)
◦
같은 코드 반복 사용
•
연상 코드
◦
품목 명칭 일부
◦
전자제품
•
코드의 오류 종류
◦
필사(Transcription) 오류
▪
1234 → 1237
◦
전위(Transposition) 오류
▪
1234 → 1243
◦
이중(Double Transposition) 오류
▪
1234 → 2143
◦
생략(Missing) 오류
▪
1234 → 123
◦
추가(Addition) 오류
▪
1234 → 12345
◦
임의(Random) 오류 (2가지 이상 오류 결합)
▪
1234 → 21345
구조적 개발 방법론
•
구조적 분석
◦
자료의 흐름, 처리를 중심으로 한 요구분석 방법
◦
정형화된 분석 절차
◦
문서화하는 체계적 분석 방법
◦
자료흐름도, 자료사전, 소단위 명세 사용
◦
하향식, 시스템 분할 가능
•
자료 흐름도
◦
버블 차트, 자료 흐름 그래프
◦
작성 원칙
▪
자료 보존
▪
최소 자료 입력
▪
독립성
▪
지속성
▪
순차 처리
◦
구성요소
•
소단위 명세서
◦
세분화된 자료 흐름도에서 최하위 단계 프로세스 처리 절차
◦
== 프로세스 명세서
◦
자료흐름도(DFD) 지원하기 위해 작성
구조적 언어, 의사 결정 나무, 의사 결정표
•
구조적 언어 : 자연어 일부분, 제한/한정된 명세서 작성에 이용
•
의사 결정 나무 : 현재 상황과 목표와의 상호 관련성을 나무의 가지를 이용해 표현한 것.
•
의사 결정표 : 복잡한 의사결정 논리를 기술하는데 사용, 자료 처리 분야에서 이용
자료 사전(DD : Data Dictionary)
•
시스템과 관련된 모든 자료의 명세와 자료 속성을 파악 할 수 있도록 조직화된 도표
•
표기법
◦
A = B : 자료의 정의
▪
~로 구성되어 있다 (is compose of)
◦
A + B : 자료의 연결
▪
그리고(and, along with)
◦
( A ) : 자료의 생략
▪
생략 가능한 자료(optional)
◦
[ A | B ] : 자료의 선택
▪
다중 택일(selection), 또는(or)
◦
{ 3 }n : 자료의 반복(iteration of)
자료 사전의 역할
•
자료 흐름도에 기술한 모든 자료의 정의를 기술한 문서
•
하향식 분할 원칙에 맞추어 구성 요소 재정의
자료 사전에서 기술해야 할 자료
•
자료 흐름을 구성하는 자료 항목
•
자료 저장소를 구성하는 자료 항목
•
자료에 대한 의미
•
자료 원소의 단위 및 값 등
모듈
모듈
•
전체 프로그램에서 어떠한 기능을 수행할 수 있는 실행 코드 의미
•
재사용 가능 - 자체적 컴파일 가능
•
기간 노동력 절감
•
모듈의 독립성은 결합도와 응집도에 의해 측정
•
= 서브루틴 = 서브 시스템 = 작업 단위
•
기능적 독립성 : 각 모듈의 기능이 서로 다른 모듈과의 과도한 상호작용을 회피함으로서 이루어지는 것
결합도(Coupling)
•
서로 다른 모듈 간의 상호 의존도 - 기능적인 연관 정도
•
결합도가 낮을 수록 좋음. - 모듈 독립성 향상, 유지보수 작업 쉬움.
•
자료 결합도가 설계 품질이 가장 좋음.
•
종류 (결합도 약한 순으로)
◦
자료 결합도
▪
자료 요소로만 구성
▪
영향 X
◦
스탬프 결합도
▪
같은 자료 구조 조회
▪
인터페이스로 전달되는 경우와 관계
◦
제어 결합도
▪
제어 신호 이용 통신
◦
외부 결합도
▪
외부 선언 변수 참조 관계
◦
공통 결합도
▪
공통 자료 영역 사용
◦
내용 결합도
▪
내부로 침투해서 조회하도록 설계
응집도(Cohesion)
•
얼마나 관련되어 있는지의 정도
•
응집도가 강할수록 좋음. - 필요한 요소들로만 구성
•
종류 (응집도 강한 순으로)
◦
기능적 응집도
◦
순차적 응집도
◦
교환적 응집도
◦
절차적 응집도
◦
시간적 응집도
◦
논리적 응집도
◦
우연적 응집도
모듈 설계 특징
•
복잡도 중복 피하고 줄이기
•
계층적 자료 조직 제시 필요
•
모듈의 크기가 작을수록 개수 증가, 통합 비용 증가
•
모듈의 크기가 클 수록 단위 모듈 개발 비용 증가
•
모듈 독립성을 높이기. - 오류발견 해결 쉬어
모듈과 컴포넌트
•
모듈
◦
스스로 동작가능한 명령의 집합
◦
인터페이스
•
컴포넌트
◦
독립적인 업무 or 기능 수행 모듈 - 교체 가능 부품
◦
모듈의 소스 코드 레벨 재활용으로 인한 한계성 극복
◦
인터페이스를 통해 연결
모듈 분할 특징
•
모듈 분할 시 영향을 주는 설계 형태
◦
추상화(Abstraction)
◦
모듈화(Modularity)
◦
정보 은폐(Information Hiding)
◦
복잡도(Complexity)
◦
시스템 구조(System Structure)
재사용
•
검증된 기능을 파악하여 재구성하는 것
•
응집도는 높게, 결합도는 낮게
재사용 규모에 따른 구분
•
함수와 객체 : 클래스와 메소드 단위
•
컴포넌트 : 자체 수정 없이 인터페이스를 통해 컴포넌트 단위로 재사
•
애플리케이션 : 공통 업무 처리 가능하게 구현된 애플리케이션 공유
공통 모듈
•
재사용 범위에 따른 분류
◦
함수와 객체 재사용
◦
컴포넌트 재사용
◦
애플리케이션 재사용
공통 모듈 - 명세 기법
•
정확성(Correctness)
•
명확성(명료성, Clarity)
•
완전성(Completeness)
•
일관성(Consistency)
•
추적성(Traceability)
모듈 명세화 도구
•
흐름도(Flowchart)
•
N-S 도표(Nassi-Schneiderman Chart)
◦
순차, 선택, 반복의 구조를 사각형으로 도식화
◦
제어 논리 구조
▪
순차(연속, Sequence)
▪
선택 및 다중 선택(If~Then~Else, Case)
▪
반복(Repeat~Until, While, For)
◦
주로 박스다이어그램 사용
•
의사 코드(Pseudo Code)
•
의사 결정표(Decision Table)
•
의사 결정도(Decision Diagram)
•
PDL(Program Design Language)
•
상태 전이도(State Transition Diagram)
•
행위도(Action Diagram)
소프트웨어 아키텍처
개요
•
요구사항을 기반으로 개발 대상 소프트웨어의 기본틀(뼈대)을 만드는 것
•
유기적 집합
•
역할 : 설계 및 구현을 위한 구조적/비구조적인 틀(Frame)을 제공
•
Structure Frame : 시스템 개발을 위하여 결정된 컴포넌트 구조 모델
•
Non Structure Frame : 해당 구조 모델 이외 다른 아키텍처 설계의 결정들
소프트웨어 아키텍처 시스템 품질 속성
•
성능, 사용 운용성, 보안성, 시험 용이성, 가용성, 변경 용이성, 사용성
소프트웨어 아키텍처 특징
•
간략성
•
추상화
•
가시성
•
복잡도 관리 종류
◦
과정 추상화
◦
데이터 추상화
◦
제어 추상화
아키텍처 프레임워크 구성 요소
•
프레임워크(FrameWork) : 복잡한 소프트웨어 문제를 해결하거나 서술하는데 필요한 기본 구조를 제공함으로써 재사용이 가능하게 해준다.
•
요소
◦
Architecture Description(AD)
▪
아키텍처를 기록하기 위한 산출물
▪
하나의 AD는 System의 하나 이상의 View로 구성
◦
이해관계자(Stakeholder)
▪
소프트웨어 시스템 개발에 관련된 모든 사람과 조직 의미
▪
고객, 개발자, 프로젝트 관리자 등을 포함
◦
관심사(Concerns)
▪
같은 시스템에 대해 서로 다른 이해관계자의 의견
◦
관점(Viewpoint)
▪
서로 다른 역할이나 책임으로 시스템이나 산출물에 대한 서로 다른 관점
◦
뷰(View)
▪
이해관계자들과 이들이 가지는 생각이나 견해로부터 전체 시스템을 표현한다.
소프트웨어 아키텍처 4+1 View Model
•
UML이 정의 되면서 4+1이 됌
•
5계층
◦
Logical View(분석 및 설계)
◦
Implementation View(프로그래머)
◦
Process View(시스템 통합자)
◦
Deployment View(시스템 엔지니어)
◦
Use Case View(사용자)
소프트웨어 아키텍처 설계 원리
•
단순성
•
효율성
•
분할, 계층화
•
추상화
•
모듈화
소프트웨어 아키텍처 평가 방법론의 종류
•
SAAM, ATAM, CBAM, ARID
소프트웨어 아키텍처 패턴
아키텍처 패턴
•
종류 : Layered, Client-Server, Mater-Slave, Pipe-Filter, Broker, Peer to Peer, Event- Bus, MVC(Model VIew Controller), Blackboard, Interperter
•
장점 : 개발 시간 단축, 고품질, 안정적, 의사소통 간편, 유지보수 유리
•
아키텍처 패턴 = 아키텍처 스타일 = 표준 아키텍처
계층(Layered) 패턴
•
N-tier 패턴
•
4계층
◦
Presentation Layer = UI 계층(UI Layer)
◦
Application Layer = 서비스 계층(Service Layer)
◦
Business Logic Layer = 도메인 계층(Domain Layer)
◦
Data Access Layer = 영속 계층(Persistence Layer)
MVC(Model View Controller) 패턴
•
Model : 핵심 기능 + 데이터
•
View : 정보 표시 (다수 뷰 가능)
•
Controller : 사용자 입력 처리
클라이언트 서버(Client Server) 패턴
•
하나의 서버, 다수의 클라이언트
•
여러 컴포넌트에 걸쳐 데이터와 데이터를 처리하는 앱에 적합
•
은행에서 주로 사용
파이프 필터(Pipe-Filters)
•
데이터 흐름(Data Stream)을 생성하고 처리하는 시스템을 위한 구조
◦
데이터 흐름 : 데이터 송/수신이나 처리의 연속적 흐름
•
필터는 파이프를 통해 받은 데이터를 변경시키고 그 결과를 파이프로 전송
•
각 처리 과정은 필터 컴포넌트에서 이루어짐
•
처리되는 데이터는 파이프를 통해 흐름 - 버퍼링, 동기화 목적 사용 가능
Peer To Peer
•
분산 컴퓨팅 앱 구축시 유연성 제공
브로커(Brocker)
•
메시지 브로커 소프트웨어에 활용
•
분산 시스템에 주로 사용
블랙보드(Black Board)
•
음성인식, 신호해석 등에 활용
이벤트 버스(Event-BUs)
•
이벤트 생성(소스)
•
이벤트 수행(리스너)
•
이벤트 통로(채널)
•
채널 관리(버스)
인터프리터(Interpreter)
•
특정 언어로 작성된 프로그램을 해석하는 컴포넌트를 설계할 때 사용
객체지향 설계
구조적 프로그래밍
•
프로그램 이해, 디버깅 작업이 쉽다.
•
GOTO(분기) 문은 사용 X
•
구조적 프로그래밍의 기본 구조
◦
순차(Sequence) 구조
◦
선택(Selection) 구조
◦
반복(Iteration) 구조
절차적 프로그래밍(Procedural Programming)
•
함수 기반 프로그래밍(C, Basic)
객체지향(Object Oriented)분석
•
현실 세계의 대상 체인 개체(Entity)를 속성(Attribute)과 메소드(Method)로 결합하여 객체(Object)로 표현(모델링)하는 것
•
기능이 아닌 개체 대상
•
JavaScript가 대표적
객체지향 구성 요소
•
Class
◦
속성 + 행위를 정의한 것 - 일반적인 Type 의미
◦
기본 사용자 정의 데이터 형 - 데이터 추상화 단위
◦
구조적 기법의 단위 테스트(Unit Test)와 같은 개념
◦
상위 클래스(부모 클래스, Super Class), 하위 클래스(자식 클래스, Sub Class)로 나뉨.
◦
Class = 틀 = Type
•
Object
◦
데이터와 함수를 묶어 캡슐화하는 대상이 됌.
◦
Class에 속한 Instance
◦
Intance : 같은 클래스에 속한 각각의 객체
◦
Object = 실체 = 변수 = Instance
•
Message
◦
Object 간에 서로 주고받는 통신 의미
객체지향의 5가지 특징
•
캡슐화(Encapsulation)
◦
서로 관련성이 높은 데이터, 기능을 묶는 기법
◦
결합도가 낮아져 재사용성 상승.
◦
정보은닉 통해 메시지 교환 시 인터페이스 단순화
◦
변경 발생 시 오류 파급 효과가 적음.
•
정보 은닉(Information Hiding)
◦
객체 내부 속성과 메소드를 숨기고 공개된 인터페이스를 통해서만 메시지를 주고 받을 수 있도록 하는 것을 의미
◦
예기치 못한 Side Effect를 줄이기 위해 사용
•
추상화(Abstraction)
◦
시스템 내 공통 성질을 추출한 뒤 추상 클래스를 설정하는 기법
◦
종류 : 기능 추상화, 제어 추상화, 자료 추상화
•
상속성(Inheritance)
◦
상위 클래스의 모든 속성, 연산을 하위 클래스가 재정의 없이 물려받아 사용하는 것
◦
상위 : 추상적 성질, 자식 : 구체적 성질
◦
다중 상속 : 다수의 상위에서 속성과 연산을 물려받는 것
•
다형성(Polymorphism)
◦
객체가 다양한 모양을 가지는 성질
◦
속성이나 변수가 서로 다른 클래스에 속하는 객체 지칭 가능 성질
◦
오버로딩(같은 이름 순서 재사용)
◦
오버라이딩(재정의) - 상속, 덮어쓰기
객체지향 기법의 관계성
•
is member of : 연관성(Association), 참조 및 이용 관계
•
is part of, part whole : 집단화(Aggregation), 객체 간의 구조적인 집약 관계
•
is a : 상속과 비슷, 일반화(Generalization), 특수화(Specialization), 클래스 간의 개념적 포함 관계
객체지향 설계 원칙(SOLID)
•
단일 책임의 원칙(SRP : Single Responsibility Principle) : 단일 목적
•
개방 - 폐쇄의 원칙(OCP : Open Closed Principle) : 확장 개방, 수정 페쇄
•
리스코프치환 원칙(LSP : Liskov Substitution Principle) - 상속
•
인터페이스 분리 원칙(ISP : Interface Segregation Principle) : 의존X
•
의존 역전 원칙(DIP : Dependency Inversion Principle)
객체지향 개발 방법론
•
Booch : OOD(Object OrientedDesign)
•
OOSE(Object Oriented SW Engineering) : Use Case 접근 방법
•
OMT(Rum-baugh)
◦
구성
▪
객체지향 분석
▪
시스템 설계
▪
오브젝트 설계/구현
◦
모델링 기법
▪
객체 모델링
▪
동적 모델링
▪
기능 모델링
•
Coad, Your-don 방법
◦
E-R 다이어그램 사용
클래스 설계
•
객체 상태 변화 모델링 필수
클래스 인터페이스
•
개발자 분류
◦
클래스 구현
◦
클래스 사용
◦
클래스 확정
협약에 의한 설계(Design by Contract) 3가지 타입
•
선행 조건
•
결과 조건
•
불변 조건
디자인 패턴
디자인 패턴 장단점
•
장점
◦
개발자 간 원활한 의사소통 지원
◦
소프트웨어 구조 파악이 쉬움
◦
재사용을 통한 개발 시간 단축
◦
설계 변경 요청에 대한 유연한 대처 가능
◦
객체지향 설계 및 구현의 생산성을 높이는 데 적합
•
단점
◦
객체지향 설계/구현 위주 사용
◦
초기 투자 비용 부담
디자인 패턴 구성
•
필수 요소
◦
패턴의 이름 : 패턴 부를 때 사용하는 이름과 패턴의 유형
◦
문제 및 배경
◦
해법 : 패턴을 이루는 요소들, 관계, 협동 과정
◦
결과 : 패턴을 사용하면 얻게 되는 이점이나 영향
•
추가 요소
◦
알려진 사례
◦
샘플 코드
◦
원리, 정당성, 근거
GoF(Gangs of Four) 디자인 패턴
•
객체지향 설계 단계 중 재사용에 관한 유용한 설계를 디자인 패턴화 했다.
•
에릭 감마, 리처드 헬름, 랄프 존슨, 존 브리시데스가 제안.
•
분류
◦
생성 패턴
객체 생성
객체 생성과 참조 과정 추상화
▪
Factory Method
•
상위 클래스 - 객체 생성
•
하위 클래스 - 인스턴스 생성
•
Virtual-Constructor 패턴
▪
Singleton
•
전역 변수 사용X - 객체 하나 생성
•
생성 객체 어디서든 참조
▪
Prototype
•
prototyped 우선 생성 ⇒ 인스턴스 복제 사용 구조
•
객체 생성
•
비용 많이 소요 되는 경우 주로 사용
▪
Builder
•
인스턴스 조립 조합 객체 생성
▪
Abstraction Factory(추상 팩토리)
•
연관, 의존적 객체들 조합 인터페이스 제공 패턴
•
관련된 서브 클래스 그룹 동시 교체 가능
◦
구조 패턴
▪
Adapter
•
기존 구현 클래스에 기능 발생 시 기존 클래스 재사용 결합 역할
▪
Bridge
•
연결 - 분리 - 변형 패턴
◦
행위 패턴
반복적 사용 객체 상호작용 패턴화
클래스나 객체들이 상호작용하는 방법과 책임을 분산하는 방법을 정의
▪
Mediator
•
객체 간의 통제와 지시의 역할을 하는 중재자를 두어 목표 달성
•
== Virtual-Constructor 패턴
인터페이스 요구사항
•
요구사항 구성, 내/외부 인터페이스 이름, 연계 대상 시스템, 연계 범위 및 내용, 연계 방식, 송신 데이터, 인터페이스 주기, 기타 고려사항
•
분류
◦
기능적 요구사항
◦
비기능적 요구사항
•
분석 절차
1.
요구 명세 작성
2.
자료 준비
3.
명세 파악 - 요구사항 구분
4.
완성도 높인다.
5.
이해관계자 공유
•
검증 절차
1.
검토 계획 수립
2.
검토, 오류 수정
3.
베이스 라인 설정
인터페이스 요구사항 검증 방법
•
프로토타이핑
•
테스트 설계
•
CASE 도구 활용
◦
Computer Aid Software Engineering
•
요구사항 검토
◦
동료 검토
◦
워크스루
▪
검토회의 전 명세서 배포 → 짦은 검토 회의 → 결함 발견
◦
인스펙션
인터페이스 대상 식별
Interface System Process
•
송신 시스템 중계 시스템 수신 시스템
중계 시스템 수신 시스템인터페이스 시스템 구성
•
송신 시스템
◦
연계할 데이터를 테이블, 파일 형태로 생성 후 전송하는 시스템
•
중계 시스템
◦
송/수신 시스템 사이에서 데이터 상태를 모니터링하는 시스템
•
수신 시스템
◦
데이털르 변환하여 DB에 저장하거나 에 활용할 수 있도록 지원하는 시스템
인터페이스 데이터 표준
•
표준 형식 정의 사용
•
공통부
◦
인터페이스 표준 항목 포함
•
개별부
◦
송/수신 시스템에서 업무 처리에 필요한 데이터 포함
•
종료부
◦
전송 데이터 끝 표시 문자 포함
•
전문 공통부(고정크기)
◦
전문 길이 10Byte
◦
시스템 공통 246Byte
◦
거래 공통 256Byte
•
전문 개별부(가변크기)
◦
데이터 nByte
•
전문 종료부
◦
전문 종료 2Byte
인터페이스 내/외부 송수신 방식
•
직접 연계 방식
◦
솔루션 사용X
•
간접 연계 방식
◦
솔루션 사용O
인터페이스 연계 기술
•
DB Link
◦
DB Link 객체 이용
◦
직접 참조 연계
•
DB Connection
◦
WAS → DB Connection Pool 생성
•
API/Open API
◦
Application Programming Interface 이용
•
JDBC
◦
JDBC 드라이
•
Hyper Link
•
Socket
◦
서버에서 통신을 위한 소켓 생성
◦
클라이언트 통신 요청 시 클라이언트와 연결하는 방식
•
Web Service
◦
WSDL, UDDI, SOAP
•
연계 솔루션
시스템 연계 기술
•
API
•
WSDL
•
UDDI
◦
XML
•
SOAP
미들 웨어
미들웨어 솔루션 정의
•
클라이언트와 서버 간의 통신을 담당하는 시스템 소프트웨어
•
표준화 연결 도와주는 소프트웨어
•
일관성 제공
•
다목적 소프트웨어
미들웨어 유형
•
데이터 베이스
•
TP-Monitor
◦
트랜잭션 감지 미들웨어
•
ORB
◦
객체지향 미들웨어
•
RPC
◦
원격 로컬 프로시저처럼 호출
•
MOM
◦
데이터베이스 시스템 데이터 동기화
•
WAS
◦
일반 웹서버와 구별
◦
HTTP를 통한 앱 수행 미들웨어
•
객체 트랜잭션 모니터
미들웨어 솔루션 분류
•
DB 미들웨어
◦
ODBC, IDAP, DRDA, OLEDB
•
통신 미들웨어
◦
RPC, DCE, MOM, ORB, OTM
