소프트웨어 공학 개요
소프트웨어
입력한 자료를 처리하여 결과를 출력하는 프로그램과 프로그램의 개발, 운용, 보수에 필요한 자료 일체
소프트웨어 공학
공학적 원리를 소프트웨어 개발에 적용하는 것
소프트웨어 개발 작업
소프트웨어 개발 작업은 요구 분석 - 설계 - 구현 - 테스트 - 유지보수 순으로 진행된다.
- 요구 분석
무엇을 개발할지 결정하는 작업
1. 도메인 분석
소프트웨어 엔지니어가 개발하려는 분야의 배경지식을 알아가는 과정
도메인이란 말은 소프트웨어를 사용할 것으로 예상되는 고객이 일하는 분야의 비즈니스나 기술을 의미
도메인 분석으로 얻을 수 있는 장점으로는 빠른 개발, 좋은 시스템, 확장 예견이 있다.
2. 요구 추출
문제를 이해하기 위해 정보를 수집하고 사용자에게 무엇이 필요한지 찾아내는 것
> 기능적 요구 : 시스템이 무엇을 하는지, 즉 사용자나 다른 시스템을 위해 제공하는 서비스가 무엇인지 기술한 것
> 비기능적 요구 : 소프트웨어를 개발하는 동안 고수해야 할 제약 조건. 사용하는 HW의 제약, SW 품질의 특성에 대한 수준의 범위를 정해놓는 것
3. 요구 문서화
문제와 현재의 상태를 파악하고 요구를 도출한 후 해결책을 제시하고 소프트웨어가 어떤 기능을 가져야 하는지 정확히는 기술하는 단계
- 설계
사용할 수 있는 기술을 이용하여 요구 사항을 어떻게 구현할 것인지 결정하는 작업
소프트웨어의 구조 설계는 매우 중요한 단계이다.
구조가 잘 설계되지 않으면 구현, 테스트, 유지 보수에 큰 어려움이 따를 것이다.
1. 설계의 접근법
> 하향식 설계
가장 높은 수준의 구조부터 시작하여 점차 낮은 수준의 구조로 내려오면서 각종 설계 이슈에 관한 의사 결정을 하는 방법
> 상향식 설계
재사용이 가능한 낮은 수준의 기능을 먼저 정한 다음, 높은 수준의 구조를 만들기 위해 이것들을 어떻게 배치할지 결정한다.
2. 설계의 종류
아키텍쳐 설계, 클래스 설계, 사용자 인터페이스 설계, 데이터베이스 설계, 알고리즘 설계, 프로토콜 설계
3. 설계안 결정
> 목표와 우선순위 결정
본격적인 설계 시작 전 여러 가지 품질 측면에 대해 목표와 우선순위를 수립해야 한다.
목표와 우선순위를 정할 때 고려할 품질은 메모리 효율성, CPU 효율성, 유지 보수성, 이식성, 사용성이다.
> 비용 효과 분석
설계할 때 고려해야 할 중요한 점은 비용을 줄이고 효과를 높이는 방법을 찾는 것이다.
- 구현
설계한 내용을 구현하는 작업
- 테스트
프로그램을 구현한 후 기능이 원하는 대로 작동하는지 테스트하는 작업
- 유지보수
개발된 소프트웨어를 완벽해질 때까지 계속 발전시켜 나가는 작업
UML(Unified Modeling Language)
UML(Unified Modeling Language)
UML은 소프트웨어를 시각적으로 모델링 하기 위해 사용한다.
소프트웨어를 모델링 하는 표준 그래픽 언어로 심볼과 그림을 사용하여 나타낼 수 있다.
UML의 목적으로는 소프트웨어 개발에 도움을 주는 것이다.
개발 과정에서 여러 다이어그램으로 설계하면 구조가 좋아지고 개발자들 간의 의사 교환이 쉬워진다.
-
우리는 UML 실습을 위해서 GitMind 홈페이지를 사용하였다.
위와 같이 사람 모형을 우리는 액터(Actor)라고 부른다.
이는 개발할 시스템의 기능을 사용하는 사용자 또는 다른 시스템을 나타내는 모형이다.
사용 사례(Use Case)는 시스템이 제공하는 개별적인 기능을 의미한다.
위 그림 속 '도서 대출 신청'은 예시 중 하나로 위와 같이 시스템이 제공하는 기능을 간단히 둥근 타원 안에 넣어 표시해 준다.
연관 관계는 유스케이스와 액터 간의 상호 작용을 의미하는 관계이다.
위와 같이 액터와 유스케이스 간의 사이를 화살표로 나타내준다.
화살표의 선이 실선, 점선이냐 등에 따라 의미하는 관계가 달라진다.
연관 관계는 액터와 유스케이스 사이에만 사용이 가능하며, 유스케이스 간의 사용은 불가능하다.
연관 관계는 액터와 유스케이스 사이의 관계를 나타낸다면, 유스케이스와 유스케이스 사이의 관계를 나타내는 것은 의존 관계로 나타낸다.
위는 포함 관계이다. 점선과 채워진 화살표와 <<include>>로 유스케이스 간의 관계를 나타낸다.
포함 관계는 한 유스케이스에서 다른 유스케이스의 기능을 반드시 포함하는 관계일 때 나타낸다.
위 예시를 보면 개인 정보 조회를 하려면 반드시 로그인이라는 기능이 필요하다.
그렇기 때문에 개인 정보 조회 유스케이스가 로그인을 포함한다는 포함 관계를 만들어준다.
위는 확장 관계이다. 한 유스케이스에서 특정 조건이나 액터의 선택에 따라 발생하는 관계를 의미한다.
점선과 빈 화살표 <<Extends>> 로 관계를 나타낸다.
위 예시에서는 파일 업로드를 하여야만 게시물을 등록할 수 있는 것이 아니라,
파일 업로드를 하지 않아도 게시글 등록이 가능하기 때문에 선택적으로 할 수 있는 기능의 관계를 나타낸 것이다.
즉, 아까 설명한 포함 관계는 반드시 해야만 하는 필수적인 관계라면, 확장 관계는 선택적으로 할 수 있는 관계를 의미한다.
위는 일반화 관계이다. 유사한 유스케이스들을 추상화한 하나의 유스케이스로 그룹핑한 관계이다.
이렇게 그룹핑을 진행할 경우 보는 사람들이 이해하기가 편하다.
위 예시를 보면 게시글 검색은 제목으로도 검색이 가능하고 내용으로도 검색이 가능하다.
그렇기 때문에 제목 검색과 내용 검색 유스케이스를 그룹핑하여 게시물 검색으로 관계를 연결해 준다.
그럼 게시글 검색이 제목과 내용을 통한 두 가지 방식의 검색이 가능하다는 것을 UML을 보는 사람이 쉽게 이해할 수 있다.
UML 다이어그램
클래스 다이어그램
시스템의 정적인 구조를 나타낸다. 또한, 도메인(문제 영역)의 개념과 그것들 사이의 관계를 표시한다.
클래스는 위와 같이 나타낼 수 있으며, 세 부분으로 나뉘어 맨 위가 클래스 이름, 속성, 메소드를 표시한다.
클래스의 이름은 단수 명사이며 대문자로 시작한다.
속성과 메소드는 생략할 수 있는데 설계 과정에서 확정되지 않은 상태를 나타낸다.
속성은 개체에 대한 정보를 나타낸다.
메소드는 메소드의 원형을 나타내어 표시하고, 메소드의 원형은 이름, 매개변수의 리스트, 반환 타입으로 나타낸다.
속성과 메소드 앞에 가시성을 표시할 수 있다.
+ : public
# : protected (상속 관계에 있을 때 자유롭게 접근이 가능하다.)
~ : default
- : private
를 나타낸다.
또한, 왼쪽 클래스 다이어그램을 보면 PI라는 속성에 밑줄이 그어져 있는데 이는 static 속성이 붙은 것이다.
추상 클래스와 추상 메소드 표현
추상 클래스는 이름 아래에 {abstract}라고 표시하여 일반 클래스와 구분한다.
추상 메소드는 구현이 없는 메소드를 의미하며 정의만 존재한다.
추상 메소드를 표현할 때에도 메소드 원형 뒤에 {abstract}라고 표시한다.
인터페이스
아래와 같이 인터페이스는 이름 위에 <<interface>>라고 표시하여 클래스와 구분한다.
연관 관계
예시를 들어보자.
클래스 A와 클래스 B는 연관 관계를 가지고 있다. 연관 관계 표시 시에 다중도를 표시하지 않으면 1로 간주된다.
다수를 나타낼 때는 아래와 같이 *로 표시한다.
객체가 없거나 한 개임을 나타낼 때는 0..1로 표시한다.
또한 객체를 표현할 때에 쉼표(,)는 또는(OR)의 의미이다.
아래 예시는 0 또는 3~8 사이를 나타낸다.
연관 관계는 방향성이 있는데 일반적으로 양방향이다.
아래와 같이 한쪽 방향으로 연관 관계를 지정할 수 있다.
아래는 일반화 관계를 나타낸 것이다. (비어있는 화살표 사용)
클래스 B는 클래스 A의 하위 클래스임을 나타낸다.
아래는 실체화 관계를 나타낸 것이다. (점선에 빈 삼각형)
클래스 B는 인터페이스 A를 실체화(구현)한다.
전체 / 부분 관계
전체 개념에 해당하는 클래스와 이를 이루는 부분(부품)에 해당하는 클래스 간의 관계이다.
아래는 집합 관계를 나타낸다.
부분(부품) 스스로 존재할 수 있는 관계이다.
실선과 흰색 다이아몬드로 표시한다.
아래는 합성 관계를 나타낸다.
부분(부품) 스스로 존재할 수 없는 관계이다.
전체 개념이 소멸될 때 부분 개념도 같이 소멸되는 관계이다.
실선과 채워진 다이아몬드로 표시한다.
