Class diagram

클래스 다이어그램은 클래스의 구성(속성+연산)과 클래스간의 관계를 표현한다. 클래스 다이어그램에 나타나는 사각형(클래스)와 원(인터페이스)가 존재한다. 클래스는 서로의 관계가 나타나야 한다. 아래 그림을 참고하여 클래스 관계를 적절하게 연결할 수 있다.

클래스는 객체를 실제화 할 수 있는 틀의 기능을 의미한다. 객체의 정보를 위한 속성과 기능인 연산으로 구성된다. 

클래스는 가시성, 타입(각 속성이 가질 수 있는 값의 범위를 결정할 때 지정), 속성의 초기값, 유도 속성, 클래스 범위의 속성과 연산 그리고 인자전달 방향이 존재한다. 

인터페이스

• 제공될 기능에 대한 명세 역할을 함
• 클래스와 달리 연산만으로 구성 됨
• 연산은 추상연산(구현의 수단이 아닌 명세이기 때문)

인터페이스 실현 관계

• 인터페이스에 기술 된 연산을 모두 구현하는 클래스/컴포넌트와 인터페이스 간의 관계
• 인터페이스 실현 틀래스는 인터페이스에 모든 연산을 구현

클래스 간의 관계

클래스 간의 관계는(연관, 집합, 일반화, 의존)

• 연관 관계: 두 개 이상의 크래스간의 관련성, 메세지 전달 통로. 시스템에서 객체는 독립적으로 존재할 수 없음
• 집합 관계: 하나의 클래스가 다른 클래스의 부분이나 구성원이 되는 의미 표현
• 일반화 관계: 유사한 두 클래스 간의 관계로서 상위 클래스가 하위 클래스보다 더 일반적인 개념을 뜻할 때 사용
• 의존 관계: 한 클래스의 변경이 다른 클래스의 수정을 유발

개념 클래스 다이어그램

• 엔티티 클래스: 영속적인 정보의 관리 기능을 하는 클래스

클래스 및 정보 추출 법은 시스템 관련 문서에서 명사를 추출하여 클래스 후보로 등록한다. 이후 불필요한 명사를 제거하고 문장 구조에서 클래스 관계를 설정한다. 일반적으로 동사를 행위로 사용한다.  또는 클래스가 될 수 있는 카탈로그를 미리 정의한 후 그것에 해당하는 명사를 추출할 수 있다.

분석 클래스 모델

분석 클래스 모델은 유스케이스 명세서를 바탕으로 분석 수준의 클래스 모델을 작성하는 것을 의미한다. 비기능적 요구사항은 고려하지 않고 기능적 요구사항만 고려한다. 운영체제, 미들웨어, 프레임워크 등의 플랫폼을 고려하지 않는다.

제어 클래스: 유스케이스의 비즈니스/제어 로직 제공

경계 클래스: 시스템과 외부 액터와의 상호 작용을 전담하는 클래스. 시스탬의 기능 중에서 입력과 출력만을 전담한다.

제어 클래스: 시스템이 실제로 제공하는 비즈니스 로직 및 제어 로직을 전담하는 클래스

엔티티 클래스: 시스템이 유지해아 하는 영속적인 데이터를 관리하는 기능을 전담하는 클래스 

프로젝트에 투입되어 소프트웨어를 개발하기 위해 우리는 클라이언트로부터 요구사항을 전달 받아야한다. 

이후 전달 받은 요구사항에 대해서 개발 할 소프트웨어의 개념적인 모델링을 진행한다. 

실제 개발되어야하는 시스템(reality)를 구성하기 위해 시스템에 대한 표현(modeling)이 되어야 하며 프로젝트의 모든 이해관계자가 한눈에 알아볼 수 있도록 진행된다. 마지막으로 구축된 model을 바탕으로 reality를 구현한다.

이 과정에서 우리는 Unified Modeling Language(UML)을 통해 모델을 표현한다. UML 2.0 버전의 경우 시스템을 구성하는구조적인 요소를 표현한 구조 다이어그램과 시스템 구성 요소들의 동적인 행위를 표현하는 행위 다이어그램으로 분류된다. 

UML을 소프트웨어 개발의 전과정에서 사용될 수 있다. 소프트웨어 개발 단계는 아래와 같다.

1. 요구사항 정의: 시스템으로부터 기능적 요구사항 도출
2. 분석단계: 시스템을 구성하는 논리적 구성 요소 도출
3. 설계단계: 시스템 구성 요소로서 논리적 컴포넌트 정의 및 설계
4. 구현 및 테스트: 앞 단계에서 작성된 모델을 바탕으로 세부적 활동 수행
5. 패키지 다이어그램: 요구사항 정의, 분석, 설계단계에서 사용

Use Case Diagrams

유스케이스 다이어그램은 시스템의 기능적 요구사항을 표현할 때 사용된다. 이는 아래의 컴포넌트로 이루어져 있다.

• 액터: 개발중인 시스템과 상호작용을 하는 시스템 외부의 존재
• 유스케이스: 시스템이 제공할 기능적 단위.
• 액터와 유스케이스의 관계: 특정기능을 위하여 어떤 액터들이 상호작용을 하는지 표현

유스케이스 다이어그램을 활용하기 위해 아래와 같은 방안이 제시된다.

• 액터의 일반화
  • 상위 액터의 특성을 하위 액터에도 동일하게 적용
• 유스케이스의 일반화
  • 유사한 유스케이스들을 일반화, 부모 유스케이스를 정의
  • 부모 유스케이스는 실제로 제공하는 기능은 아님
  • 추상 유스케이스는 이텔릭체로 표기
• 유스케이스의 포함
  
  • 유스케이스의 공통 기능을 추출, 별도의 유스케이스 정의
• 유스케이스의 확장
  • 기존 유스케이스에 없는 기능을 별도의 유스케이스로 표현
• 액터 간의 연관 관계
  • 액터 간의 상호작용

아래 그림은 유스케이스 다이어그램의 예시를 보여준다.

Use case model

유스케이스 모델은 액터와 유스케이스 간의 관계를 보여준다. 액터와 유스케이스 사이의 연관 관계는 해당 유스케이스의 기능과 관련이 있는 액터를 명시함으로 써 생성된다. 액터와 액터 사이의 일반화 관계(상속 관계)는 상위 액터의 특성이 하위 액터에도 적용됨을 뜻한다. 유스케이스 사이의 포함 관계(include)는 하나 이상의 유스케이스에 존재하는 공통적인 기능을 추출해 별도의 유스케이스를 정의하는 것이다. 유스케이스 사이의 확장 관계(extend)는 기존 유스케이스와 성갹이 다른 추가적인 기능을 별도의 유스케이스로 표현하는 것이다. 

Use case Specification

유스케이스 명세서는 유스케이스 모델에 기술된 개별 유스케이스에 대한 구체적이고 상세한 기능을 정의한 문서이다. 유스케이스의 명세서를 구성하는 주요 항목은 아래와 같다. 

• 유스케이스 이름: 유스케이스에 대한 가장 간결한 명세서로 유스케이스를 통하여 제공되는 시스템의 기능을 명확한 동사 구 형태로 표현
• 개요: 모든 이해관계자는 가장 먼저 유스케이스 명세서의 개요 항목을 통해서 유스케이스 이해
• 관련 액터 항목: 해당 유스케이스가 동작할 때 필요한 주변 액터 이해 가능. 주 액터와 보조 액터를 구분하여 기록
• 우선 순위: 기능의 중요도와 개발 난이도를 바탕으로 결정. 개발 순서, 자원 투입 등과 같이 프로젝트 관리 측면에서 활용
• 선행 조건: 유스케이스의 종료 시 만족해야 하는 조건으로 유스케이스의 정상 동작 여부에 대한 최소한의 판단 기준으로 사용 가능
• 시나리오: 유스케이스의 관련 액터와 시스템 간의 상호작용에 대한 구체적인 정의 포함. 하나의 유스케이스에는 기본 시나리오와 대안 시나리오로 구분하여 기술
• 비 기능적 요구사항: 성능, 신뢰도, 보안 등 이 유스케이스와 관련된 비 기능적 요구사항 기술

객체 지향은 소프트웨어 공학도로써 필히 알아야하는 기본 개념중 하나이다. 소프트웨어를 하나의 큰 틀에서 바라보는 것이 아닌 여러 객체의 모음으로 하나의 소프트웨어를 생산하는 관점으로 봐야한다.

객체 지향은 '공통 경험과 실제 객체가 서로 관련되는 방식을 많이 활용하는 소프트웨어를 개발하고 패키징 하는 방법' 으로 정의할 수 있다. 즉 각 객체는 속성과 기능을 가지고 이 객체들이 서로 연관(relation)되어 하나의 완전한 소프트웨어로 발돋음 되는 것이다. 

객체 지향의 구성은 아래와 같다. 

• Abstraction
• Encapsulation
• Moduarity
• Hierarchy

Abstraction은 어떤 사물에 대해 내부의 세세한 것을 숨기고 외부에는 중요한 특징만 공개하는 방식을 의미한다. 소프트웨어는 이러한 '추상화'가 잘되는가 안되는가에 따라 외부에서 접근이 되는지(개발자 영역을 일반 사용자가 볼 수 있는지)를 검토해야 한다. 

Encapsulation은 연관되어 있는 속성과 기능을 하나의 클래스로 묶는 것을 의미한다. 이때 데이터를 중심으로 이 데이터를 사용하여 처리하는 기능들을 하나의 클래스로 묶을 수 있다.

Hierarchy는 어떠한 클래스가 다른 클래스를 부모로 상속 받고 자식 관계를 만들어 나아가며 최종적으로 객체 간의 계층적인 구조가 만들어지는 것을 의미한다. 모든 클래스에 통용되는 기능을 부모 클래스로 넣고 자식 클래스는 이를 상속받아서 사용할 수 있도록 구현한다.

객체 지향의 주요 개념은 아래와 같이 나뉠 수 있다.

• Object
• Encapsulation
• Information Hiding
• Class
• Inheritance
• Polymorphism

Object란 real-world 도메인을 여러 객체로 표현하는 것을 의미한다. 하나의 객체은 데이터와 기능을 가지고 있으며 데이터는 상태(state)를, 기능은 오브젝트의 행동(operation)을 가진다. 객체의 상태는 개체의 특성을 나타내며 variable로 표현할  수 있다. 이는 값을 가질 수 있다. 상태의 특성은 변하지 않으나 그 값은 변한다. 객체의 행위는 상태의 값을 변경시킬 수 있는 행위이다. 이는 class의 여러 method로 표현된다. 

 여기서 짚고 넘어가야할 것이 객체와 클래스의 관계이다. 현실 도메인에서 객체를 추출하고 이를 추상화 하여 클래스로 만든다. 역으로 클래스를 구체화 하여 객체를 생성할 수도 있다. 

Encapsulation은 서로 연관되어있는 데이터와 행위를 하나로 묶는 것을 의미한다. 

Information Hiding은 객체를 하나의 black box로 취급하여 일부 정보는 은폐하고 일부는 공개하는 것을 의미한다. 아래 그림은 객체와 사용자간의 정보 공유의 차이점을 보여준다. 

information hiding을 할 경우 해당 객체는 독립성, 유지보수성, 확장성 그리고 추상화의 개념이 나타나게 된다. 

Class는 object의 카테고리를 의미하는 더 큰 object이다. 하나의 클래스는 하나의 오브젝트 타입을 소프트웨어로 적용한 것을 의미한다. 따라서 class는 여러 object간의 집합이라 할 수 있다. 하나의 클래스는 여러 자료 구조와 기능들을 포함하며 이는 각 오브젝트에 적용될 수 있다. Class를 이루는 내용중 자주 접할 수 있는 단어 Instance가 있다. Instance는 클래스에 속한 하나의 오브젝트를 의미하고 클래스 내 모든 오브젝트는 같은 세트의 속성과 메소드를 가진다. 또 클래스에 대해 공부하고 있다면 생성자에 대한 개념도 알게 된다. 생성자란 클래스 이름과 동일한 이름을 가진 메소드로 인스턴스를 생성한다. 생성을 했다면 소멸도 해야한다. 따라서 소멸자는 생성된 객체 인스턴스를 메모리로 부터 제거하며 현재 사용중인 거의 대부분의 객체 지향 언어는 객체가 제거될 경우 자동적으로 하위 인스턴스를 메모리에서 free 시키도록 구현되어있다.

Inheritance는 상위 클래스의 속성 또는 행위를 하위 클래스가 상속하여 재 사용하는 것을 의미한다. 아래 그림을 통해 이해하자. 

Ploymorphism은 함수를 overloading하는 것을 의미하는데, 같은 메세지에 응답하는 두개 이상의 오브젝트의 능력이라고 정의할 수 있다. 

소프트웨어는 기능, 개발 과정 그리고 하드웨어 환경에 따른 분류로 나뉠 수 있다. 

• 기능적 분류
  
  • 응용 S/W
  • 시스템 S/W
  • 임베디드 S/W
• 개발 과정에 따른 분류
  
  • Prototype
  • Product
  • Package
• 하드웨어 환경에 따른 분류
  
  • 분산 시스템 S/W
  • PC & Workstation
  • 모바일 S/W

이 분류 외에 소프트웨어의 성격에 따른 분류도 나눌 수 있다. 

• System Software
• Business Application Software
• Engineering/Scientific Software
• Real-time software
• Embedded Software
• Web applications
• Artificial Intelligent Software
• Ubiquitos

[System Software]

시스템 소프트웨어는 응용 프로그램을 실행하기 위해 기본이 되는 소프트웨어를 의미하며 unix, windows와 mac os 등이 있다. 또한 컴파일러와 에디터 같은 몇몇 시스템 소프트웨어는 복잡한 과정을 독립적으로 수행하기도 하며 컴퓨터의 성능을 좌우하기도 한다. 기본적으로 C/C++ 기반 언어로 작성되어있다.

[Business Application Software]

비지니스 응용 소프트웨어는 사업 관계에서 사용하기 유용한 시스템을 의미하며 대학 포털 시스템, 이지바로 등이 있다. 일반적으로 공통 이해관계를 가진 다수의 사용자가 하나의 시스템에 접속하여 활동함으로 대용량 데이터베이스와 연동되어 있는 경우가 많으며 클라이언트-서버 구조를 가져 웹을 통한 접속이 가능하다. 기본적으로 웹 어플리케이션에 최적화 되어있는 Java를 사용하며 C/C++도 큰 비중을 차지한다.

[Real-Time Software]

실시간 처리가 가능해야 하는 소프트웨어로 THAAD와 같은 전시 상황에 쓰이는 경우가 많다. 언어 의미 그대로 실시간 처리가 가능해야 함으로 고급 언어 중 가장 빠른 실행 속도를 가지는 C/C++로 작성되어있다. 근대에서는 Real-Time이라는 별도의 소프트웨어보다는 인공지능 분야에 적용하여 자율주행과 같은 시너지를 내기도 한다.

[engineering/Scientific Software]

수치 데이터를 다루는 소프트웨어이다. 일반적으로 물리, 통계, 선형대수 등에서 많이 사용된다. 주로 사용되는 언어는 C/C++과 수치해석에 특화 된 R, Matlab과 Fortran을 사용한다. 이 분야 또한 인공지능 분야에 적용하여 시너지를 내기도 한다.

[Embedded Software]

read-only 메모리의 컨트롤과 시스템 컨트롤을 수행하는 소프트웨어이다. 제한적이거나 중요한 기능을 수행한다. 우리가 실생활에 사용하는 휴대폰, 차량과 로봇등에 사용된다. 

[Artificiatl Intelligent Software]

인공지능 분야의 소프트웨어이다. 4차 산업 혁명의 주 축인 인공지능을 이용하여 회귀, 분류와 군집화 등의 작업을 수행하며 빅데이터 처리 시 높은 수준의 평가 지표를 산출 할 수 있다. 패턴 인식, 자연어 처리, 테이블 데이터 처리 등 다방면에 접목할 수 있다. 주로 사용되는 언어는 Python이고 몇몇 인공지능 모델은 C를 사용하여 추론 시간을 대폭 향상시키기도 한다. 

통상 소프트웨어와 프로그램은 같은 의미로 쓰이곤 한다. 그러나 엄밀히 말하자면 두 단어는 다른 뜻을 가지고 있다.

• Program : A set of instructions written by any programming language
• Software : Programs, data and associated documentation

위 정의에서 말하듯 소프트웨어는 high-level 언어로 짜여진 프로그램과 데이터를 연결한 document이자 상품이다.

소프트웨어 상품은 특정 고객 또는 일반 시장을 위해 개발된다. 따라서 일반적(Generic)인 특성을 띌수도, 맞춤화된(Bespoke)특성을 띌수도 있다. 

소프트웨어 개발 프로젝트가 시작된다면 아래와 같은 절차를 거쳐 구현하는 것이 바람직하다.

각 단계별로 수행되어야 하는 목표를 알아보자. 

• 요구사항 정의
  • 클라이언트와 대화를 통해 요구사항 도출
• 분석(명세)
  • 클라이언트의 요구사항 분석 및 명세 문서의 형태로 표현
  • 소프트웨어 프로젝트 관리 계획이 작성됨
• 설계
  • 아키텍쳐 설계
    • 상품을 모듈이라 불리는 컴포넌트로 분리
  • 상세 설계
    • 모듈 알고리즘 및 UI/UX 설계
    • 상품이 어떻게 수행되는지 기술한 설계 문서 작성
• 구현
  • 컴포넌트를 하나의 시스템으로 통합하고 전체적인 테스트 진행
  • 상품의 기능이 정확하게 구현될 경우 클라이언트가 수행 테스트 수행
  • 상품이 클라이언트에 의해 승인되고 실제 운용상태에 들어가기 직전 단계임
• 유지보수
  • 상품이 클라이언트에게 인도되고 승인 테스트를 마친 이후 부터 상품을 수정하는 모든 활동 의미
    • 완전적 유지보수(prefective maintenance) : 약 60.3% 
    • 적응적 유지보수(adaptive maintenance) : 약 18.2%
    • 수정적 유지보수(corrective maintenance) : 약 17.4%

잘 짜여진 소프트웨어 개발 주기를 통해 만들어진 상품은 클라이언트의 만족도를 높게 받을 수 있을 뿐만 아니라 유지보수 시 필요한 시간적, 공간적 자원을 절약할 수 있다.

우리는 소프트웨어의 특성을 파악해 위와 같은 주기를 계획할 수 있다. 

• Testability
• Conformity / Changeability
• Longevity
• Duplicability
• Application dependability

소프트웨어는 test가 가능하다. 구현 단계에서 이를 통해 시스템적인 오류 및 결측 사항을 확인할 수 있을 뿐만 아니라 버그와 보안 취약점과 같은 문제 또한 수정 가능하다. 

소프트웨어는 언제든 교체가 가능하다. 현업에서 사용중인 수 많은 소프트웨어는 지속적인 업데이트를 요구한다. 그러나 소프트웨어를 업데이트 하는 과정에서 우리가 서비스 센터에 방문해 해야하는 등의 추가적인 지연 없이 클릭 몇번으로 가능하다. 이 특성은 소프트웨어 개발자 뿐만 아니라 소비자 또한 만족도가 높은 소프트웨어의 특징이다.

소프트웨어는 닳지 않는다. 따라서 오랜 기간을 사용해도 성능에 변화가 없다. 사실 이 특징은 온전히 '소프트 웨어' 에만 초점을 맞춘 특징이지 소프트웨어를 운용하는 하드웨어는 수명이 존재한다. 

소프트웨어는 덮어쓰기가 가능하다. 다른 사람이 배포한 코드를 우리 문제에 맞게 수정해 사용할 수 있어 업무의 효율성이 증가한다.

소프트웨어는 어플리케이션에 의존해야 한다. 소프트웨어의 특성상 보이지 않기 때문에(invisible) UI/UX 등과 연동된 통합 어플리케이션으로 결과를 출력해야한다. 따라서 어플리케이션에 의존적일 수 밖에 없다.