[정처기] 1과목 소프트웨어설계
1과목 소프트웨어설계
소프트웨어
특징: 상품성, 복잡성, 변경가능성, 복제성
시스템 기본요소: 조직, 입력, 처리, 출력, 제어, 피드백
소프트웨어 위기
- 하드웨어 비용을 초과하는 개발 비용
- 개발 기간 지연
- 개발 인력 부족 및 인건비 상승
- 성능 및 신뢰성 부족
- 유지보수 어려움
소프트웨어 공학
저비용, 빠르고 쉽고 정확하게 만든느 방법
기본요소: 현대적인 프로그래밍 기술 전용, 신뢰성, 사용성, 유지보수성, 지속적인 검증
재공학
기존에 만든 것 재사용
- 개발 시간 및 비용 감소
- 품질, 생산성, 신뢰성 향상
- 구축방법 공유
- 프로젝트 실패 위험 감소
목적
- 유지보수성 향상
- 복잡한 시스템 다루는 방법 구현
- 다른 뷰 생성
- 잃어버린 정보 복구 및 제거
- 재사용 수월, 소프트웨어 수명 연장
과정
분석 → 구성 → 역공학 → 이식
역공학
분석, 문서화
CASE(Computer Aided Software Engeennring)
소프트웨어 개발을 도와주는 자동화 도구
- 소프트웨어 생명주기 전체 단계 연결, 자동화, 통합
- 문서화, 명세화를 위한 그래프 제공
- 개발 단계 표준화, 자료 흐름도 작성 기능 제공
- 모델 사이 모순 검사, 소프트웨어 개발 모형 제공
원천 기술: 구조적 기법, 프로토타이핑 기술, 정보 저장소 기술
장점: 개발 기간 단축, 비용 절약, 생산성 향상, 문서화 도구
상위 CASE - 요구분석 설계
하위 CASE - 실제 구현
통합 CASE - 소프트웨어 개발 주기 전체 과정 관리
도구: SADT 블록 다이어그램 지원
소프트웨어 개발 주기
타당성 검토 → 개발 계획 → 요구사항 분석 → 설계 → 구현 → 테스트 → 운용 → 유지보수
소프트웨어 개발 방법론
폭포수 모형(Waterfall)
소규모 개발
변경사항 반영 어려움
나선형 모델(Spiral)
계획 수립 → 위험 분석 →개발/검증(+프로토타입 개발) →고객평가 →...(계획 수립 단계로)
상향식 설계
기본 기능 먼저
HIPO Hierarchy Input Process Output
계층적 입력 처리 출력
하향식 소프트웨어 개발을 위한 문서화 도구
가시적 도표, 총체적 다이어그램, 세부적 다이어그램
V-모델
폭포수 모형의 시스템 검증과 테스트 작업을 강조한 모델
HIPO에 테스트 추가
애자일(Agile)
절차, 도구보다 목표에 중점
고객과 소통하여 고객이 원하는 것 빠르게 개발
종류: XP, 스크럼, 린, DSDM, FDD, Crystal, ASD, DAD
XP 핵심가치: 소통, 단순성, Feedback, 용기, 존중
Spike(요구사항 확인 프로그램) → Release Planning → Iteration → Acceptance Test → Small Release
+ User Story
Fine Scale Feedback: Pair Programming, Planning Game, Test Driven Development, Whole Team(사용자를 팀원으로)
Continuous Process: Continuous Integration, Design Improvement, Small Releases
Shared Understanding: Coding Standard, Collective Code Ownership, Simple Design, System metaphor
Programmer Welfare: Sustainable Pace
Scrum
제품 책임자(개발 의뢰자), 스크럼 마스터, 스크럼 팀
Product Backlog: 요구사항을 우선 순위에 따라 나열한 목록
현행 시스템 분석
1단계: 시스템 구성(업무 흐름/조직) 파악 → 시스템 기능 파악 → 시스템 인터페이스 현황 파악(데이터 연계 유형, 형식, 종류, 프로토콜, 주기)
2단계: 아키텍처 파악 → 소프트웨어 구성 파악(품명, 용도, 라이선스)
3단계: 시스템 하드웨어 현황(컴퓨터 사양, 서버 이중화) 파악 → 네트워크 구성 파악
EAI Enterprise Application Integration
FEP FrontEnd Processor
시스템 아키텍처
시스템 내의 상위 시스템과 하위 시스템이 어떠한 관계로 상호작용하는지 각각의 동작원리와 구성을 표현한 것
플랫폼
응용 소프트웨어 + 하드웨어 + 시스템 소프트웨어
종류: JAVA, .NET, IOS, Android, Windows
특성 분석 항목: 응답 시간, 가용성, 사용률
테스트 방법: 기능 테스트, 사용자 인터뷰, 문서 점검
OS 분석
종류: Windows, Android, IOS, UNIX, LINUX, MAC OS
분석 항목: OS 종류, 버전, 패치 일자, 백업 주가
고려사항: 가용성, 성능, 기술 지원, 주변 기기, 구축 비용(TCO: 자산 획득에 필요한 직/간접적 총 비용-교육, 기술지원, 유지보수, 에너지 사용 비용), 메모리 누수
오픈소스 라이선스
GNU(GNU is Not UNIX): 유사 UNIX
GNU GP Lv1: 소스 코드 공개 의무
Apache 2.0 ex) Android, HADOOP
DBMS 분석
종속성, 중복성 문제 해결
종류: Oracle, IBM DB2, Microsoft SQL Server, MySQL, SQ Lite, MangoDB, Redis
고려사항: 가용성, 성능, 기술지원, 상호호환성, 구축 비용
요구사항
자료 흐름도, 자료 사전, 소단위 명세서
목적: 누락 방지, 상호 이해, 요구사항 변경 이력 관리, 비용/일정 제약 설정, 타당성 조사, 요구사항 정리 문서화
요구 공학: 사용자의 요구를 정확히 반영한 시스템 개발을 위해 추출, 분석, 명세, 검증, 관리하는 구조화된 활동 집합
SWEBOK
1. 도출: 현상태 파악, 문제 정의
(고객 발표, 문서 조사, 설문, 업무 절차 및 양식 조사, 브레인스토밍, 워크숍, 인터뷰, 관찰 및 모델 프로토타이핑, UseCase, 벤치마킹, BPR-업무 재설계, RFP-제안요청서)
2. 분석: 문제 인식, 전개, 평가와 종합, 검토, 문서화
기능/비기능 요구사항(기술 내용), 시스템/사용자 요구사항(관점, 대상)
(사용자 의견, 인터뷰, 문서 분석/중재, 관찰 및 모델 작성 기술, 설문 조사)
3. 명세: 정확성, 명확성, 완전성, 일관성, 수정 용이성, 추적성
정형(수학) | 비정형(상태, 객체) | |
종류 | Z, VDM, Petri-Net, LOTOS, CSP, CCS | FSM(Finite State Machine), Decision Table, ER 모델링, State Chart(SADT), UseCase, 사용자 기반 모델링 |
장점 | 정확, 간결 | 이해 용이, 전달 방법 다양 |
단점 | 낮은 이해도 | 불충분, 모호 |
4. 확인: 요구사항 관리 도구 필요성, 변경 비용, 편익 분석, 변경 추적, 형상 관리(개발 단계의 모든 프로그램, 문서, 데이터 => 버전 관리)
(프로토타이핑, 모델 검증, 요구사항 검토, 인수 테스트)
정형 분석: 요구사항을 구문과 형식적으로 정의된 의미를 지닌 언어로 표현, 오해 최소화, 요구사항 분석 마지막 단계
프로토타이핑
추가 요구사항 도출
요구사항 분석 → 프로토타입 설계 → 프로토타입 개발 → 고객 평가 → 프로토타입 정제 → 완제품 생산
단점: 사용자의 관심이 퀄리티에 집중될 수 있음, 제작 비용, 사용성 과대평가
모델 검증
분석 단계에서 개발된 모델의 품질 검증
정적 분석: 객체 모델들 사이 Communication Path 검증, 명세의 일관성, 정확성 확인
동적 분석: 직접 실행
인수테스트
설계 시 제시한 요구사항을 만족하는지 확인
종류: 계약, 규정, 사용자, 운영 인수 테스트, 알파/베타 검사
개념 모델링 Conceptual Modeling
요구사항 분석 도구
종류: Use Case Diagram, Data Flow Model, State Model, Goal-Based Model, User Interactions, Object Model, Data Model
UML Unified Model Language
객체지향 소프트웨어 산출물을 명세화, 시각화, 문서화할 때 사용하는 모델링 기술과 방법론을 통합하여 만든 범용 모델링 언어
구성: 사물, 관계, 다이어그램
스테레오 타입: UML에서 제공하는 기본 요소 외에 추가적인 확장 요소를 표현할 때 사용 길러멧 Guillemet << >>
접근 제어자: Public(+), Private(-), Protected(#), Package(~)
구조적 다이어그램(Structure Diagram): Class Diagram, Object Diagram, Composite Structure Diagram(복합체 구조), Deployment Diagram(배치), Component Diagram, Package Diagram
행위 다이어그램(Behavior Diagram): Use Case Diagram, Activity Diagram, State Machine Diagram, Collaboration Diagram
- 상호작용 다이어그램: Sequence Diagram(생명선, 통로, 상호작용, 실행, 상태불변, 메시지, 활성, 객체, Actor), Timing Diagram, 상호작용 개요 Diagram, Communication Diagram
Rumbaugh 객체 모델링(객체 다이어그램), 동적 모델링(상태 다이어그램), 기능 모델링(데이터 흐름도)
특징: 비주얼화, 문서화, 명세화, 구축
정적 관점: 구조 관계 Class Diagram
동적 관점: 내부 동작 Sequence Diagram, State Diagram, Activity Diagram
기능적 관점: 사용 사례 모델링 Use Case Diagram
Class Diagram
객체 관계를 추상화, 속성, 오퍼레이션을 가짐
UML 관계
단방향 | 화살표 | 상대방은 모름 |
양방향 | 실선 | 서로 앎 |
의존 | 점선 화살표 | 일시적 |
일반화 | 세모 화살표 | 상속 관계 |
집합 | 빈 마름모 화살표 | 전체/부분이 같음 |
포함 | 마름모 화살표 | 라이프타임 의존적(강한 집합) |
실체화 | 점선 세모 화살표 | 책임 집합 인터페이스(행동) |
UML 연관 관계: 객체와 객체(이름, 역할, 연관 관계, 다중성)
Use Case Diagram
요소: 시스템 경계(범위), Actor(이용 주체, 외부 객체), Use Case, Communication, Association, Uses Association, Extends Association
작성 단계: 액터 식별 → Use Case 식별 → 관계 정의 → Use Case 구조화
소프트웨어 아키텍처
소프트웨어 아키텍처 품질 요구사항: 사용자의 요구사항(기능, 성능 만족도)을 얼마나 충족하는가
ISO/IEC 9126 모델
품질 특성 평가
내외부 품질: 기능성, 신뢰성, 사용성, 효율성, 유지보수성, 이식성
사용 품질: 효과성, 생산성, 안정성, 만족도
외부지표: 사용자, 시험자, 평가자 및 개발자의 품질 평가(실행 가능 SW)
내부지표: 실행 불가 SW에 대해 적용(명세서, 원시코드 등)
ISO/IEC 25010: 9126 특성기준 확대
UI 환경 분석
- 기능 조작성 분석:사용자 편의(스크롤바, 마우스 조작 동선)
- 오류 방지 분석
- UI 정보 전달력 확인(오류 발생 시 해결 방법)
요구사항 요소: 데이터, 기능, 제품/서비스 품질, 제약사항
정황 시나리오 작성
특징: 사용자 만족도에 직접 영향, 편리성, 가독성, 동선 축약, 효율성
기능: 입력 검증, 에러, 에러 메세지 처리, 도움과 프롬프트(커서) 제공
설계 원칙: 직관성, 유효성, 학습성, 유연성
설계 지침: 사용자 중심, 일관성, 단순성, 가시성, 표준화, 접근성, 결과 예측 가능, 명확성, 오류 발생 해결
구현 표준: UI 요소, 배치 규칙, 화면 구성, 화면 이동
한국형 웹 콘텐츠 접근성 지침 2.1: 인식의 용이성, 윤용의 용이성, 이해의 용이성, 견고성
UI 설계 단계: 문제 정의 → 사용자 모델 정의(타겟) → 작업 분석 → 컴퓨터 오브젝트 및 기능 정의(기기) → 사용자 인터페이스 정의(마우스 등) → 디자인 평가(GOMS:사용자 행위 예측, Heuristics:어림짐작)
UI 상세 설계
UI 메뉴 구조 설계, 내/외부 화면과 폼 설계, UI 검토 수행
UI 상세 설계 시나리오 작성 원칙
기능, 작동 방식을 개발자가 쉽게 이해하도록 구체적으로 작성
Tree, FlowChart 표기법 이용
공통 UI 요소, 상호작용 정의
예외 상황 정의
UI 일반 규칙을 따라 기능별 상세 기능 시나리오 정의
시나리오 작성 요건: 완전성, 일관성, 이해성, 가독성, 수정 용이성, 추적 용이성
UI 설계 도구
와이어 프레임: 핸드라이팅, 파워포인트, 키노트, Sketch, Balsamiq, Mockup, Adobe Experience Design, 카카오 오븐
목업: 카카오 오븐, Balsamiq, Mockup, Power Mockup
프로토타입: HTML/CSS, Axure, Invision Studio, 카카오 오븐, Flinto, 네이버 Proto Now
스토리보드
프로토타입 제작 단계
요구분석 → 프로토타입 작성 → 프로토타입 사용자 테스트 → 수정과 합의 단계
감성 공학 접근 방법
1류(의미 미분법): 감각, 감성 표현
2류: 1류 + 평가자 생활 양식 추가
3류: 평가자가 시제품을 사용 - 감각 척도로 감성 표출
HCI Humon Computer Interaction/Interface: 인간과 컴퓨터 상호작용
목적: 인간의 창의력, 인간간 의사소통, 협력 증진
감성 공학 요소 기술: 기초 기술, 구현 기술, 응용 기술
소프트웨어 설계 모델링
목적: 관점을 "무엇"에서 "어떻게"로 전환하면서 소프트웨어의 청사진을 만드는 것
분류
- 상위 설계: 아키텍처 설계 - 데이터 설계 - 인터페이스 정의 - 사용자 인터페이스 설계
- 하위 설계: 모듈 설계 - 자료구조 설계 - 알고리즘 설계
소프트웨어 설계 대상
구조 모델링: 컴포넌트 유형, 인터페이스/내부설계구조 상호 연결
행위 모델링: 어떤 순서로 기능 수행, 상호작용
소프트웨어 설계 방법
구조적 설계: 기능(자료처리 과정, 알고리즘) Coad/Yourdon
자료 중심 설계: 입출력 자료 구조 Jackson Warner-Orr
객체지향 설계: Yourdon, Sheller/Meller, Rumbaugh, Booch
소프트웨어 구조도
Fan-in 상위 모듈 수
Fan-out 하위 모듈 수
Depth 깊이
Width 같은 레벨 모듈 수
Super ordinate 다른 모듈을 제어하는 모듈
Subordinate 제어되는 모듈
Fan-in이 높은 경우 재사용성 높음, 단일 장애 발생 가능-중점 관리 필요
Fan-out이 높은 경우 불필요한 타모듈 호출 여부 확인-단순하게 설계할 수 있을지 검토
복잡도 최적화: Fan-in 높이고 Fan-out 낮추기
코드 설계
기본 기능: 표준화, 간소화
3대 기능: 분류, 식별, 배열
부가 기능: 연상, 암호화, 오류 검출
목적/특성: 고유성, 분류 편의성
종류: 순차 코드(항목이 적고 변경이 적은 자료), 블록 코드(추가가 쉬우나 코드 낭비), 그룹 분류식 코드(대중소), 10진분류코드(ex.도서분류코드), 표의숫자코드(길이,무게 등 의미있는 숫자), 연상코드(품목명칭일부포함)
코드 오류: 필사, 전위, 이중, 생략, 추가, 임의
구조적 개발 방법론
구조적 분석: 정형화된 분석 절차에 따라 사용자 요구사항 파악, 문서화 - 자료 흐름도, 자료 사전, 소단위 명세서
자료흐름도(버블 차트)
입출력 중심
변환 형태: 본질, 합성, 관점, 구성
원칙: 자료 보존, 최소 자료 입력, 독립성, 지속성, 순차 처리, 영구성
동그라미 | 자료 변환 프로세스 |
화살표 | 자료 이동 |
위아래줄(양옆이 뚫린 네모) | 자료 저장소 |
네모 | 단말 - 자료 발생지/도착지(사람/조직체) |
소단위 명세서(프로세스 명세서)
자료흐름도 지원 용도
서술 문장, 구조적 언어, 의사결정 나무, 의사결정표(판단표), 그래프
자료 사전
자료흐름도 지원 용도
= | + | () | [ | ] | {} | * * |
정의 | 연결 | 생략 | 선택 | 반복 | 설명(주석) |
모듈
= 서브 루틴 = 서브 시스템 = 작업 단위
결합도 상호 의존도
(낮음)자료-스탬프-제어-외부-공통-내용(높음)
응집도 모듈 요소들의 관련성
(강함)기능적-순차적-교환적-절차적-시간적-논리적-우연적(약함)
N-S 도표
모듈 명세화 도구
순차, 선택, 반복 구조를 사각형으로 도식화, 알고리즘
소프트웨어 아키텍처
시스템 품질 속성 성능, 사용운용성, 보안성, 시험용이성, 가용성, 변경용이성, 사용성
소프트웨어 아키텍처 특징 간략성, 추상화, 가시성, 복잡도 관리 종류
소프트웨어 아키텍처 설계 원리 단순성, 효율성, 분할/계층화, 추상화, 모듈화
소프트웨어 아키텍처 평가방법론 SAAM, ATAM, CBAM, ARID
종류
Layered, Client-Server, Master-Slave, Pipe-Filter, Broker, Peer to Peer(분산 컴퓨팅), Event-Bus, MVC, Blackboard, Interpreter
Pipe-Filter
장점: 필터 교환, 재조합 → 유연
단점: 상태 공유 비용, 데이터 변환 과부하
활용: 컴파일러, 어휘 분석, 구문 분석, 의미 분석, 코드 생성
아키텍처 프레임워크 구성요소
Architecture Description
Stakeholder
concerns
viewpoint
view
4+1 View model
Logical view 분석 및 설계
Implementation view 프로그래머
Process view 시스템 통합자
Deployment view 시스템 엔지니어
Usecase view 사용자
객체지향설계
구성요소
Object(Attribute, Method), Message(Object간 통신), Class(유사한 객체)
특징 캡슐화, 정보은닉, 추상화(기능, 제어, 자료), 상속성, 다형성
관계성 is member of(연관성), is part of(집단화), is a(일반화, 특수화)
오버로딩 한 클래스 내부 이름이 같은 메서드. 매개변수 타입, 개수로 구분
오버라이딩 하위 클래스에서 메서드 재정의(덮어쓰기)
객체지향 설계 원칙 SOLID
SRP Single Responsibility Principle
OCP Open Closed Principle(확장 개방 수정 폐쇄)
LSP Liskov Substitution Principle(부모 클래스를 자식 클래스로 치환 가능)
ISP Interface Segregation Principle(인터페이스 분리 원칙)
DIP Dependency Inversion Principle(의존 역전 원칙)
종류
OOD(Booch), OOSE(Jacopson), OMT(Rumbaugh), Coad/Yourdon(E-R다이어그램)
클래스 설계 타입
선행 조건, 결과 조건, 불변 조건
디자인 패턴
장점 객체지향설계/구현. 생산성을 높임
단점 객체지향 위주, 초기투자 비용
구성요소 패턴 이름, 문제/배경, 해법, 결과(+사례, 샘플코드, 원리, 정당성, 근거)
GoF 디자인 패턴
재사용
생성: Factory Method, Singleton, Prototype, Builder, Abstraction Factory
구조: Adapter, Bridge
행위: Mediator
인터페이스 요구사항 확인
검증 방법: 프로토타이핑, 테스트 설계, CASE, 요구사항검토(동료검토, 워크스루, 인스펙션)
인터페이스 시스템 구성 송신 시스템, 중계 시스템, 수신 시스템
인터페이스 연계 기술 DB Link, DB Connection(WAS), API/OpenAPI, JDBC, Hyper Link, Socket, Web Service(WSDL, UDDI, SOAP), 연계 솔루션(EAI)
미들웨어 솔루션
종류: DB, TP-Monitor(Transaction Processing), ORB(Object Request Broker), RPC(Remote Procedure Call), MOM(Message Oriented Middleware), WAS, OTM(ORB + TP Monitor)
분류: DB 미들웨어(APP to Data), 통신 미들웨어(APP to APP)
Web Client → Web Server → WAS
** 참고