[소프트웨어공학] 7장 Design and Implementation

이전까지 요구사항을 정의를 하고 시스템의 아키텍처까지 정의를 했다.

top-down 방식에서 설계자와 구현자가 다를 수 있다.

각각을 세분화해서 설계와 구현을 분리할 수도 있는 반면 에이자일과 같은 경우에는 설계와 구현이 밀 결합되어있다.

 

주요의제

• Object-oriented design using the UML – 폭포수 기법이건 에이자일 기법이건 UML을 적용은 같지만 사용용도는 다를 수 있음

밑에 것들은 개발에 연관성이 더 높다

• Design patterns
• Implementation issues
• Open source development

 

소프트웨어 상세설계와 구현을 통해서 결과로는 실행 가능한 시스템이 나온다.

상세설계와 구현하는 사람이 다르다면 서로 대화를 많이 해야 한다.

더불어 같다면 에이자일 기법과 같은 것들이 많이 쓰인다.(일반 설계과정이 간소화될 수 있음)

상세설계 - 시스템에 등장하는 요소들을 정의하고 상호관계 역시 정의해준다. 하나하나 진행된다.

 

Build or buy -> 가장 고민을 우선적으로 하는 것

-COTS(Commercial-off-the-shelf) 시스템을 사는 것

-시스템을 무조건적으로 개발을 하는 것이 아님(사오는 것이 더 이득이라면 사옴, 또는 비슷한 오픈소스를 변형해서 사용)

 

>Object-oriented design using the UML

객체지향 설계 기법을 상세설계 단계에서 사용할 수 있음.

작은 규모의 시스템이라면 객체지향 시스템에서 일부분만을 추출해서 사용함.

공통적으로 포함되는 과정

- Define the context and modes of use of the system(우리의 시스템이 할 것과 하지 않을 것에 대한 경계를 정의함.)

- Design the system architecture(우리가 해야 할 것과 다른 것들의 상호작용을 시스템레벨에서 정의함)

- Identify the principal system objects(시스템의 내부에 구성요소를 정의함)

아래 두 과정에서 내부, 외부에서의 상호작용을 정의함

- Develop design models

- Specify object interfaces

 

 

System context and interactions – 우리 시스템의 경계를 정의하는 것이 중요

-System context – 시스템의 상호작용을 구조화함

-interaction model – 상호작용을 그림과 같은 것들로 나타냄, 유스케이스를 사용함

예시

필요할 때에 필요한 만큼을 적절하게 사용하면 됨

우리의 시스템과 외부의 시스템 간의 상호작용

상세설계 – 객체 간의 상호적용이 어떻게 이루어지는지, 경험이 매우 중요하다.

 

>Approaches to identification

-grammatical approach

-behavioural approach

-tangible things(하드웨어와 관련된 것들)

class는 우리가 문장을 구성함에 있어 주어나 목적어를 주로 사용한다.

동사가 함수나, 클래스의 맴버 메서드로 많이 구현이 된다.

-scenario-based analysis -> 누가 누구에게 어떤 행동을 하는지가 들어난다. 시퀀스 차트를 만들어 보면 시스템의 행동과 관계 같은 것들을 구현해 낼 수 있다.

ex. weather station 예시

센서들을 추출해서 각각에 상응하는 객체를 만들 수 있다.

weather station -> 외부와의 상호작용을 담당

weather data -> 센서에서 받은 데이터를 저장

예시 그림

 

공통적인 것은 -> 유전의 법칙으로 묶음

Sequence model – 동적인 행동을 표현

State machine model – 바뀌는 상태를 표현

 

>Subsystem models

여기 안에도 클래스가 존재할 수 있다

 

시퀀스 다이어그램 – 위에서 아래로 시간 변화로 진행된다.

상태 다이어그램 – 각각의 변화 상태 별로 동작을 보여준다.

 

>>이러한 표현들은 앞서 과정에서도 많이 사용하지만 특히 상세설계 단계에서 주로 사용된다.

 

 

>Design patterns – 지금까지 쌓여온 지식

>>코드의 재사용, 설계의 재사용

>>설계에 대한 안전성이 생김

>>다형성, 객체지향을 통해 설명함

pattern – 이미 설계되어 있는 패턴들을 잘 공부하고 있으면 사용에 유용하다

 

 

패턴구성

-이름

-문제 상황

-패턴의 동작(솔루션)

-기대되는 장단점

 

>>코드뿐만 아니라 설계 자체도 재사용함

 

ex. 제 3자적 시점에서 쳐다봄(Observer pattern)

이름 - Observer pattern

개요 – 데이터는 변형하는 관점과 보는 관점이 분리되는 것

문제 – 하나의 데이터가 목적에 따라 다양한 형태로 보여지는 것

어떻게 할 것인가? - UML을 통해서 보여준다

예상되는 결과의 장단점 – 최적화하는 방법이 필요하다.

 

좀 더 세세한 설명 표, 그림 예시

솔루션에는 정적인 측면과 동적인 측면이 기술되어 있다.

단점

보편화해서 만들어졌기 때문에 특정적인 것은 개발자의 별도의 개발이 필요하다.

Observer가 Subject를 has함(has-relationship)

다양한 패턴의 종류

>Observer pattern – 데이터를 변경시키지 않고 보는 것

>Façade pattern – 사용자에게 뒤쪽 부분을 많이 안보이게 하는 것

>Iterator pattern – for문을 사용할 때

>Decorator pattern – 게임에서 많이 사용

 

Implementation issues(구현을 할 때 많이 언급이 되는 것)

>Reuse(재사용) - 백지상태에서 시작x, 기존에 있는 것을 변경, 변화시키는 방향으로 진행함

초기에는 대부분의 소프트웨어를 새로 짰지만 현재는 누적된 데이터들과 통신이 가능해지면서 이전에 만들어졌던 것들을 공유하여 활용함.

 

단계

abstraction level – 디자인에 대한 재사용

object level – 코드를 재사용

component level – 클래스들을 재사용

system level – 시스템을 통째로 재사용

>>재사용을 한다고 해서 비용이 안 드는 것은 아님(어느 정도 요구사항에 맞춰서 수정이 필요할 수 있기 때문에)

 

 

 

 

>Configuration management(형상관리) – 소프트웨어에서 버전관리를 하는 것(추적관리)

소프트웨어가 변화하는 것을 관리하는 것

Version management – 버전을 관리하는 것, 소프트웨어는 버전들이 서로 연결이 되어 있음.

System integration – 시스템 통합

Problem tracking – 버그가 발생하면 찾고 수정하고 적용한다.

 

>Host-target development – 특정한 하드웨어, 소프트웨어를 사용하거나 개발할 때 서로 다른 환경에서 진행된다면 이것 역시 고려해주어야 한다.

개발하는 환경과 운영하는 환경이 다른 것

 

Integrated development environments (IDEs)

통합 개발 환경

 

 

>Open source development

>>소스코드가 오픈되어 있는 것

>>Freedom으로 생각

>>재사용이 활성화(인터넷을 통해)

>>ex. 리눅스

2가지 관점

-재사용

-여러 사람들과 함께 개발하기 위함

 

Open source issues(오픈소스를 통한 수익창출)

레드헷과 같은 회사들의 수익창출방법

네이버나 카카오, 구글 같은 회사들은 인하우징이 가능하지만

삼성이나 현대 같이 직접 소프트웨어를 만드는 곳이 아니라면 직접 개발보단 사서 사용하는 것이 비용이 덜 들어 갈 수 있음 -> 따라서 기존에 있던 오픈소스에 부족한 부분을 채워서

기술지원(support)이라는 명목으로 돈을 받음.

 

Open source licensing -> 오픈소스는 항상 권한이 존재한다!

License models

>GPL – 우리 오픈소스를 사용했으면 그것도 오픈해라!

>LGPL – 별도의 소스코드를 그대로 별로도로 만들어서 링크만 걸어서 사용 -> 소스코드를 안 공개해도 됨.

>BSD – 사용된 곳을 명시하고 가져다 사용함

 

 

License management

-회사를 만든다면 라이센스에 대한 관리가 필요하다.

-오프소스에 대한 정보도 필요하다

-오픈소스에 대한 교육이 필요하다.

-오픈소스를 사용했다면 그곳에 기여하는 것이 필요하다.

 

7장 요약

- 소프트웨어 설계 및 구현은 상호간 활동입니다. 설계의 상세 수준은 시스템의 유형과 계획 기반 또는 신속한 변화를 위한 접근 방식을 사용하는지에 따라 달라집니다.

- 객체 지향 설계 프로세스에는 시스템 아키텍처 설계, 시스템 내 객체 식별, 다양한 객체 모델 사용 설계 설명 및 구성요소 인터페이스 문서화가 포함됩니다.

- 객체 지향 설계 프로세스 중에 다양한 모델이 생산될 수 있습니다. 여기에는 정적 모델(클래스 모델, 일반화 모델, 연관 모델)과 동적 모델(시퀀스 모델, 상태 기계 모델)이 포함된다.

- 구성요소 인터페이스는 다른 오브젝트가 사용할 수 있도록 정확하게 정의되어야 합니다. 인터페이스를 정의하기 위해 UML 인터페이스 고정 관념(stereotype)을 사용할 수 있다.

- 소프트웨어를 개발할 때는 항상 기존 소프트웨어를 부품, 서비스 또는 전체 시스템으로 재사용할 수 있는 가능성을 고려해야 합니다.

- 형상관리(Configuration management)는 발전하는 소프트웨어 시스템의 변경사항을 관리하는 프로세스입니다. 한 팀의 사람들이 소프트웨어를 개발하기 위해 협력할 때 그것은 필수적이다.

- 대부분의 소프트웨어 개발은 호스트 타겟 개발입니다. 호스트 시스템의 IDE를 사용하여 소프트웨어를 개발하고, 이 소프트웨어는 실행을 위해 대상 시스템으로 전송됩니다.

- 오픈 소스 개발은 시스템의 소스 코드를 공개하는 것을 포함한다. 이는 많은 사람들이 소프트웨어에 대한 변경과 개선을 제안할 수 있다는 것을 의미한다.