개발의변화
1 소프트웨어 개발 방법론 2. 사용자 인터페이스 본문
소프트웨어 생명주기(SDLC; Software Development Life Cycle)
소프트웨어 생명주기는 시스템의 요구분석부터 유지보수까지 전 공정을 체계화한 절차
1. 폭포수 모델
소프트웨어 개발 시 각 단계를 확실히 마무리 지은 후에 다음 단계로 넘어가는 모델
2. 프로토타이핑 모델
고객이 요구한 주요 기능을 프로토타입으로 구현하여, 고객의 피드백을 반영하여 소프트웨어를 만들어내는 모델
3. 나선형 모델
시스템 개발 시 위험을 최소화하기 위해 점진적으로 완벽한 시스템으로 개발해나가는 모델
4. 반복적 모델
구축대상을 나누어 병렬적으로 개발 후 통합하거나, 반복적으로 개발하여 점증 완성시키는 SDLC모델
애자일 방법론
절차보다는 사람이 중심이 되어 변화에 유연하고 신속하게 적응하면서 효율적으로 시스템을 개발할 수 있는 신속 적응적 경량 개발 방법론
XP: 의사소통 개선과 즉각적 피드백으로 소프트웨어 품질을 높이기 위한 방법론
용기: 용기를 가지고 자신감 있게 개발
단순성: 필요한 것만 하고 그 이상의 것들은 하지 않음
의사소통: 개발자, 관리자, 고객 간의 원활한 소통
피드백: 의사소통에 대한 빠른 피드백
존중: 팀원 간의 상호 존중
스크럼: 매일 정해진 시간, 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심 방법론
린: 도요타의 린 시스템 품질기법을 소프트웨어 개발 프로세스에 적용해서 낭비 요소를 제거하여 품질을 향상시킨 방법론
객체 지향 기법
캡슐화: 서로 연관된 데이터와 함수를 함꼐 묶어 외부와 경계를 만들고 필요한 인터페이스만을 밖으로 드러내는 기법
결합도가 낮아지고 재사용이 용이
인터페이스가 단순화됨
상속성: 상위 클래스의 속성과 메서들르 하위 클래스에서 재정의 없이 물려받아 사용하는 기법
다형성: 하나의 메시지에 대해 각 객체가 가지고 있는 고유한 방법으로 응답할 수 있는 능력
상속받은 여러 개의 하위 객체들이 다른 형태의 특성을 갖는 객체로 이용될 수 있는 성질
오버로딩: 매개변수의 유형과 개수를 다르게 하여 같은 이름의 메서드를 여러 개 가지는 기법
오버라이딩: 상위 클래스에서 정의한 일반 메서드의 구현을 하위 클래스에서 무시하고 재정의할 수 있는 기법
정보 은닉: 코드 내부 데이터와 메서드를 숨기고 공개 인터페이스를 통해서만 접근이 가능하도록 하는 코드 보안 기술
추상화: 공통 성질을 추출하여 추상 클래스를 설정하는 방법
관계성: 두 개 이상의 엔티티 형에서 데이터를 참조하는 관계를 나타내는 기법
객체 지향 설계 원칙(SOLID
단일 책임의 원칙(SRP): 하나의 클래스는 하나의 목적을 위해서 생성, 클래스가 제공하는 모든 서비스는 하나의 책임을 수행하는 데 집중되어야 한다는 워칙
개방 폐쇄 원칙(OCP;lOpenClosePrinciple): 소프트웨어의 구성요소는 확장에는 열려있고, 변경에는 닫혀있어야 한다는 원칙
리스코프 치환의 원칙(LSP; Liskov Substitution Principle) 서브 타입은 어디서나 자신의 기반 타입으로 교체할 수 있어야 한다는 원칙
인터페이스 분리의 원칙(ISP; Interface Segregation Priniciple) 한 클래스는 자신이 사용하지 않는 인터페이스는 구현하지 말아야 한다는 원칙
의존성 역전의 원칙(DIP; Dependency Inversion Principle) 실제 사용 관계는 바뀌지 않으며, 추상을 매개로 메시지를 주고받음으로써 관계를 최대한 느슨하게 만드는 원칙
OOSE(Object Oriented Software Engineering) 야콥슨
유스케이스에 의한 접근 방법으로 유스케이스를 모든 모델의 근간으로 활용하는 방법론
OMT(Object Modeling Technology) 럼바우
그래픽 표기법을 이용하여 소프트웨어 구성요소를 모델링하는 방법론
비용산정 모형 종류
LoC(Lines of Code) 모형
LoC 모형은 소프트웨어 각 기능의 원시 코드 라인 수의 낙관치, 중간치, 비관치를 측정하여 예측치를 구하고 이를 이용하여 비용을 산정하는 방식
Man Month모형
Man Month모형은 한 사람이 1개월 동안 할 수 있는 일의 양을 기준을 ㅗ
(Man Month) = (LoC)/(프로그래머의 월간 생산성)
(프로젝트 기간) = (Man Month)/(프로젝트 인력)
COCOMO 모형
COCOMO 모형은 보헴(Boehm)이 제안한 모형으로 프로그램 규모에 따른 비용을 산정
비용산정 결과는 프로젝트를 완성하는 데 필요한 노력(Man-Month)으로 산정
조직형(Organic Mode): 기관 내부에서 개발된 중 소규모 소프트웨어로 일괄 자료 처리나 과학 기술 계산용, 비즈니스 자료 처리 개발에 적용, 5만 라인 이하의 소프트웨어를 개발하는 유형
반 분리형: 단순형과 임베디드형의 중간형, 30만 라인 이하의 소프트웨어를 개발하는 유형
임베디드형(Embedded Mode) : 초대형 규모의 트랜잭션 처리 시스템이나 운영체제, 실시간 처리 시스템 등 시스템 프로그램 개발에 적용 30만라인 이상의 소프트웨어를 개발하는 모형
푸트남 모형(Putnam)
소프트웨어 개발주기의 단계별로 요구할 인력의 분포를 가져가는 모형
기능점수(FP; Function Point) 모형
요구 기능을 증가시키는 인자별로 가중치를 부여하여
FP = 총 기능점수 X [0.65 + (0.1 X 총 영향도)]
일정관리 모델 종류
주 공정법: 여러 작업의 수행 순서가 얽혀 있는 프로젝트의 일정을 계산하는 기법, 모든 자원 제약사항을 배제한 상태로 프로젝트의 시작과 끝을 내느 노드와 노드 간을 연결을 통해 공정을 계산하기 위한 엑티비티 표기법
중요 연쇄 프로젝트 관리(CCPM)
주 공정 연쇄법으로 자원제약사항을 고려하여 일정을 작성하는 기법
디자인 패턴 유형
목적 - 생성: 객체 인스턴스 생성에 관여, 클래스 정의와 객체 생성 방식을 구조화, 캡슐화를 수행하는 패턴
구조: 더 큰 구조 형성 목적으로 클래스나 객체의 조합을 다루는 패턴
행위: 클래스나 객체들이 상호 작용하는 방법과 역할 분담을 다루는 패턴
범위 클래스: 클래스 간 관련성(상속 관계를 다루는 패턴), 컴파일 타임에 정적으로 결정
객체: 객체 간 관련성을 다루는 패턴, 런타임에 동적으로 결정
디자인 패턴 종류
생성 패턴
Builder
복잡한 인스턴스를 조립하여 만드는 구조로, 복합 객체를 생성할 떄 객체를 생성하는 방법과 객체를 구현하는 방법을 분리함으로써 동일한 생성 절차에서 서로 다른 표현 결과를 만들 수 있는 패턴
Prototype
처음부터 일반적인 원형을 만들어 놓고, 그것을 복사한 후 필요한 부분만 수정하여 사용하는 패턴으로, 생성할 객체의 원형을 제공하는 인스턴스에서 생성할 객체들의 타입이 결정되도록 설정하며 객체를 생성할 대 갖추어야 할 기본 형태가 있을 떄 사용되는 디자인 패턴
Factory Method
상위 클래스에서 객체를 생성하는 인터페이스를 정의하고, 하위 클래스에서 인스턴스를 생성하도록 하는 방식으로, 상위 클래스에서 인스턴스를 만드는 방법만 결정하고, 하위 클래스에서 그 데이터의 생성을 책임지고 조작하는 함수들을 오버라이딩하여 인터페이스와 실제 객체를생성하는 클래스를 분리할 수 있는 특성을 갖는 디자인 패턴
Abstarct Factory
구체적인 클래스에 의존하지 않고 서로 연관되거나 의존적인 객체들의 조합을 만드는 인터페이스를 제공하는 패턴으로 이 패턴을 통해 생성된 클래스에서는 사용자에게 인터페이스(API)를 제공하고, 구체적인 구현은 Con-crete Product클래스에서 이루어지는 특징을 갖는 디자인 패턴
Singleton
전역 변수를 사용하지 않고 객체를 하나만 생성하도록 하며, 생성된 객체를 어디에서든지 참조할 수 있도록 하는 디자인 패턴
구조 패턴
Bridge
기능의 클래스 계층과 구현의 클래스 계층을 연결하고, 구현부에서 추상 계층을 분리하여 추상화된 부분과 실제 구현 부분을 독립적으로 확장할 수 있는 디자인 패턴
Decorator
기존에 구현되어 있는 클래스에 필요한 기능을 추가해 나가는 설계 패턴으로 기능 확장이 필요할 떄 객체 간의 결합을 통해 기능을 동적으로 유연하게 확장할 수 있게 해주어 상속의 대안으로 사용하는 디자인 패턴
Facade
복잡한 시스템에 대하여 단순한 인터페이스를 제공함으로써 사용자와 시스템 간 또는 여타 시스템과의 결합도를 낮추어 시스템 구조에 대한 파악을 쉽게 하는 패턴
FlyWeight
다수의 객체로 생성될 경우 모두가 갖는 본질적인 요소를 클래스 화하여 공유함으로써 메모리를 절약하고 '클래스의 경량화'를 목적으로 하는 디자인 패턴
Proxy
실제 객체에 대한 대리 객체로 실제 객체에 대한 접근 이전에 필요한 행동을 취할 수 있게 만들며, 이 점을 이용해서 미리 할당하지 않아도 상관없는 것들을 실제 이용할 때 할당하게 하여 메모리 용량을 아낄수 있었다
행위 패턴
Mediator
객체 지향 설계에서 객체의 수가 너무 많아지면 서로 간 통신을 위해 복잡해져서 객체 지향에서 가장 중요한 느슨한 결합의 특성을 해칠 수 있기 떄문에 이를 해결하는 방법으로 중간에 이를 통제하고 지시할 수 있는 역할을 하는 중재자를 두고, 중재자에게 모든 것을 요구하여 통신의 빈소를 줄여 객체 지향의 목표를 달성해주는 패턴
Interpreter
언어의 다양한 해석, 구체적으로 구문을 나누고 그 분리된 구문의 해석을 맡는 클래스를 각각 작성하여 여러 형태의 언어 구문을 해석할 수 있게 만드는 패턴
Iterator
컬렉션 구현 방법을 노출시키지 않으면서도 그 집합체 안에 들어있는 모든 항목에 반복자를 사용하여 접근할 수 있는 디자인 패턴
내부구조를 노출하지 않고, 복잡 개체의 원소를 순차적으로 접근 가능하게 해주는 행위 패턴
Template Method
어떤 작업을 처리하는 일부분을 서브 클래스로 캡슐화해 전체 일을 수행하는 구조는 바꾸지 않으면서 특정 단계에서 수행하는 내역을 바꾸는 패턴
Observer
한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체들에 연락이 가고 자동으로 내용이 갱신되는 방법으로 일대 다의 의존성을 가지며 상호 작용하는 객체 사이에서는 가능하면 느슨하게 결합하는 디자인 패턴
State
객체 상태를 캡슐화하여 클래스화함으로써 그것을 참조하게 하는 방식, 상태에 따라 다르게 처리할 수 있도록 행위 내용을 변경하여, 변경 시 원시 코드의 수정을 최소화 할 수 있고, 유지보수의 편의성도 갖는 디자인 패턴
Visitor
각 클래스 데이터 구조로부터 처리 기능을 분리하여 별도의 클래스를 만들어 놓고 해당 클래스의 메서드가 각 클래스를 돌아다니며 특정 작업을 수행하도록 만드는 패턴, 객체의 구조는 변경하지 않으면서 기능만 따로 추가하거나 확장할 떄 사용하는 디자인 패턴
Command
실행될 기능을 캡슐화함으로써 주어진 여러 기능을 실행할 수 있는 재사용성이 높은 클래스를 설계하는 패턴으로 하나의 추상 클래스에 메서드를 만들어 각 명령이 들어오면 그에 맞는 서브 클래스가 선택되어 실행되는 특징을 갖는 디자인 패턴
Strategy
알고리즘 군을 정의하고 같은 알고리즘을 각각 하나의 클ㄹ스로 캡슐화한 다음 필요할 때 서로 교환해서 사용할 수 있게 하는 패턴으로, 행위를 클래스로 캡슐화해 동적으로 행위를 자유롭게 바꿀 수 있게 해주는 디자인 패턴
요구사항의 분류
기능적 요구사항: 시스템이 제공하는 기능, 서비스에 대한 요구사항
특정 입력에 대해 시스템이 어떻게 반응해야 하는지에 대한 기술, 어떻게 동작해야 하는지에 대한 기술
비기능적 요구사항: 시스템이 수행하는 기능 이외의 사항, 시스템 구축에 대한 제약사항에 관한 요구사항
품질 속성에 관련하여 시스템이 갖춰야할 사항에 관한 기술, 시스템이 준수해야 할 제한 조건에 관한 기술
도분명확
비정형 명세 기법: 사용자의 요구를 표현할 때 자연어를 기반으로 서술하는 기법, 사용자와 개발자의 이해가 용이
정형 명세 기법: 사용자의 요구를 표현할 떄, 수학적인 원리와 표기법으로 서술하는 기법, 표현이 간결, 명확성 및 검증이 용이, 기법의 이해가 어려움
UI 요구사항 확인
UI(User Interface)
넓은 의미에서 사용자와 시스템 사이에서 의사소통할 수 있도록 고안된 물리적, 가상의 매개체
좁은 의미로는 정보 기기나 소프트웨어의 화면 등에서 사람이 접하게 되는 화면
CLI(Command Line Interface)
정적인 텍스트 기반 인터페이스, 명령어를 텍스트로 입력하여 조작하는 사용자 인터페이스
GUI(Graphical User Interface)
그래픽 반응 기반 인터페이스, 그래픽 환경을 기반으로 한 마우스나 전자펜을 이용하는 사용자 인터페이스
NUI(Natural User Interface)
직관적 사용자 반응 기반 인터페이스, 키보드나 마우스 없이 신체 부위를 이용하는 사용자 인터페이스
OUI(Organic User Interface)
유기적 상호 작용 기반 인터페이스 ,현실에 존재하는 모든 사물이 입출력장치로 변화할 수 있는 사용자 인터페이스
UI 설계 원칙
직관성: 누구나 쉽게 이해하고, 쉽게 사용할 수 있어야 함 / 쉬운 검색, 쉬운 사용량, 일관성
유효성: 정확하고 완벽하게 사용자의 목표가 달성될 수 있도록 제작 / 쉬운 오류 처리
학습성: 초보와 숙련자 모두가 쉽게 배우고 사용할 수 있게 제작 / 쉽게 학습, 쉬운 접근 ,쉽게 기억
유연성: 사용자의 요구사항을 최대한 수용하고, 실수를 방지할 수 있도록 제작/ 오류 예방, 실수포용, 오류 감지
스토리보드
UI화면 설계를 위해서 정책이나 프로세스 및 콘텐츠의 구성, 와이어프레임, 기능에 대한 정의, 데이터베이스의 연동 등 구축하는 서비스를 위한 대부분 정보가 수록된 문서
와이어프레임
이해 관계자들과의 화면구성을 협의하거나 서비스의 간략한 흐름을 공유하기 위해 화면 단위의 레이아웃을 설계하는 작업
프로토타입
정적인 화면으로 설계된 와이어프레임 또는 스토리보드에 동적 효과를 적용하여 실제 구현된 것처럼 시뮬레이션 할 수 있는 모형
UML
객체 지향 소프트웨어 개발 과정에서 산출물을 명세화, 시각화, 문서화할 떄 사용되는 모델링 기술과 방법론을 통합해서 만든 표준화된 범용 모델링 언어
UML의 특징
가시화 언어: 개념 모델 작성 시 오류가 적고 의사소통이 용이
구축 언어: 다양한 프로그래밍 언어로 실행 시스템의 예측 가능, UML을 소스 코드로 변환하여 구축 가능, 역 변환하여 역공학 가능
명세화 언어: 정확한 모델 제시, 완전한 모델 작성 기능
문서화 언어: 시스템에 대한 평가 및 의사소통 문서
UML의 구성요소
사물(Things): 추상적인 개념으로, 주제를 나태는 요소, 단어 관점에서 '명사' 또는 '동사'를 의미
관계(Relationships): 사물의 의미를 확장하고 명확히 하는 요소, 사물과 사물을 연결하여 관게를 표현하는 요소, 단어 관점에서 '형용사' 또는 '부사'를 의미
다이어그램(Diagrams):
사물과 관계를 모아 그림으로 표현한 형태, 형식과 목적에 따라 9가지로 정의
UML의 스테레오 타입 '<<>>'(길러멧: Guillemet) 기호를 사용
유즈케이스 다이어그램
- 시스템이 제공하고 있는 기능 및 그와 관련된 외부 요소를 사용자의 관점에서 표현하는 다이어그램
- 유즈케이스(시스템이 제공해야 하는 서비스), 액터(사용자가 시스템에 대해 수행하는 역할), 시스템(전체 시스템의 영역을 표현), 시나리오(발생되는 이벤트의 흐름)
- 시스템
전체 시스템의 영역을 표현
시퀀스 다이어그램
- 객체 간 상호 작용을 메시지 흐름으로 표현한 다이어그램
- 객체 간의 동적 상호 작용을 시간적 개념을 중심으로 모델링하는 과정이다
- 객체의 오퍼레이션과 속성을 상세히 정의해야 한다
- 유스케이스를 실현한다
객체: 위쪽에 표시되며 아래로 생명선을 가짐, 사각형 안에 밑줄 친 이름으로 명시
생명선: 객체로부터 뻗어 나가는 점선, 실제 시간이 흐름에 따라 객체의 생명주기 동안 발생하는 이벤트를 명시
실행: 직사각형은 오퍼레이션이 실행되는 시간을 의미, 직사각형이 길어질수록 오퍼레이션 수행시간이 긺
메시지: 객체 간의 상호 작용은 메시지 교환으로 이루어짐, 한 객체에서 다른 객체로의 메시지를 전달하여 전달받은 객체의 오퍼레이션 수행
패키지 다이어그램
패키지: 요소들을 그룹으로 조직하기 위한 요소
의존관계: 하나의 패키지가 다른 패키지를 사용하는 관계, 의존성의 성질을 나타내기 위해 스테레오 타입을 붙일 수 있음, 스테레오 타입 <<import>>, <<access>>
활동 다이어그램
시스템이 어떤 기능을 수행하는지를 객체의 처리나 조건에 따른 처리의 흐름을 순서대로 표현하는 다이어그램이다.
오퍼레이션이나 처리과정이 수행되는 동안 일어나는 일들을 단계적으로 표현한다.
상태 다이어그램
하나의 객체가 자신이 속한 클래스의 상태 변화 혹은 다른 객체와의 상호 작용에 따라 상태가 어떻게 변화하는지 표현하는 다이어그램
클래스 다이어그램: 객체 지향 모델링 시 클래스의 속성 및 연산과 클래스 간 정적인 관계를 표현한 다이어그램
클래스: 공통의 속성, 연산, 관계, 의미를 공유하는 객체들의 집합
속성: 클래스의 구조적 특성에 이름을 붙인 것으로 특성에 해당하는 인스턴스가 보유할 수 있는 값의 범위를 기술
연산: 이름, 타입, 매개변수들과 연관된 행위를 호출하는데 요구되는 제약사항들을 명시하는 클래스의 행위적 특징
접근 제어자: 클래스에 접근할 수 있는 정도를 표현
'-' : 클래스 내부 접근만 허용(private),
'+': 클래스 외부 접근만 허용(public),
'#': 동일 패키지/파생 클래스에서 접근 가능
'~': 동일 패키지/클래스에서 접근 가능(protected),
클래스 간의 관계
연관 관계: 연관 관계는 클래스가 서로 개념적으로 연결된 선, 연관 관계는 2개 이상의 사물이 서로 관련되어 있는 상태를 표현, 사물 사이를 실선으로 연결하여 표현하며 방향성은 화살표로 표현, 서로에게 영향을 주는 양방향의 경우 화살표 생략
의존 관계: 하나의 클래스가 또 다른 클래스를 사용하는 관계, 다른 클래스의 멤버 함수 사용, 사물 사이에 서로 연관은 있으나 필요에 따라 서로에게 영향을 주는 짧은 시간 동안만 연관을 유지하는 관계를 표현
일반화 관계: 하나의 사물이 다른 사물에 비해 더 일반적인지 구체적인지를 표현, 일반적인 개념을 부모라고 하고, 구체적인 개념을 자식이라고 함
실체화 관계: 추상 클래스나 인터페이스를 상속받아 자식 클래스가 추상 메서드를 구현할 떄 사용, 사물이 할 수 있거나, 해야 하는 기능으로 서롤르 그룹화할 수 있는 관계를 표현
포함 관계: 영구적이고, 집합 관계보다 더 강한 관계로 구성, 포함되는 쪽에서 포함하는 쪽으로 속이 채워진 마름모를 연결하여 표현
집합 관계: 하나의 객체에 여러 개의 독립적인 객체들이 구성되는 관계, 집합 관계는 하난의 사물이 다른 사물에 포함되어 있는ㄴ 관계 표현