시스템 아키텍처(system architecture)
- 시스템 아키텍처 정의
시스템 아키텍처에 대한 정의는 다양하며 몇 가지 공통적인 사항을 정리하면 다음과 같 다. 우선 시스템 아키텍처는 시스템의 구성 및 동작 원리를 도식화하여 표한한 것이다. 시 스템의 구성 요소 혹은 구성 부품에 대한 설계 및 구현에 대한 상세한 사항을 기술한 것 으로 정의하기도 한다. 시스템을 구성하는 다양한 구성 요소 간의 관계 및 시스템 외부 환경과의 관계가 상세하게 도식화되어 있으며 구체적인 구성 요소의 요구 사양 및 시스템 의 전체 수명 주기를 기술하기도 한다. 마지막으로 시스템 전체(하드웨어와 소프트웨어를 포괄한 것)에 대한 논리적인 기능 체계와 그것을 실현하기 위한 구성 방식 및 시스템의 전체적인 최적화를 목표로 기술되어 있는 도식화된 기술서로 정의하기도 한다. 즉, 시스템 이 어떻게 작동하는지를 설명하는 것으로, 구동 목적을 달성하기 위하여 시스템 각 요소 가 무엇이며 어떻게 작용하여 정보를 교환하고 반응하는지를 기술로 정의할 수 있다.
- 소프트웨어 아키텍처 설계 절차
시스템 아키텍처 설계는 하위 구성 요소들 간의 관계를 정의하는 작업이다. 시스템 아키 텍처 설계의 주요 목적은 시스템의 구조를 세분화하여 정의하고 하위 구성 요소들 간의 제어 및 정보 공유 관계를 기술하는 것이다. 시스템 아키텍처 설계를 위해 구조적 설계 기법에서는 자료 흐름도를 사용하고 객체지향 설계 기법에서는 클래스 다이어그램을 사용 하여 점진적인 도식화 과정을 거친다.
소프트웨어 아키텍처 특성
설계 프로세스는 반복적인 활동들의 집합으로서 설계자는 이러한 반복 과정을 통해 개발 할 소프트웨어 구조, 하부 단위, 정보, 인터페이스 등과 같은 소프트웨어의 모든 분야를 상세하게 설계하게 된다. 소프트웨어 아키텍처 설계는 개발할 소프트웨어의 전체 구조를 설계하는 기본적인 업무에서 하위 단위 사이에 주고받는 정보나 하위 단위에 대한 설계 같은 세부적인 사항을 포함한다.
- 소프트웨어 아키텍처 추상화(abstraction)
일반적으로 복잡한 문제 해결을 위하여 초기에 세부 사항을 먼저 설계하기보다는 전체적 이고 포괄적인 개념을 설계한 후 차례로 세분화하여 점진적으로 구체화시키는 방법이다. 단계적인 정제(refinement)를 통해서 기본 설계에서 상세 설계로 나아가면 추상화의 수준 은 낮아지고, 원시 코드가 생성될 때 추상화는 최하위 수준이 된다. 설계 단계에서 사용되 는 추상화의 예로는 제어 추상화, 과정 추상화 및 데이터 추상화가 있다.
도형이나 블록으로 구조, 컨셉, 메모, 정리를 한다고 생각하면 됩니다. 하나의 큰 기능 또는 동작(실행) 목적으로부터 세부기능을 정의하고 각 구분된 항목들이 기능, 제어 그리고 자료 관점에서 대략적인 입출력들을 정의를 시작합니다.
- 단계적 정체(stepwise refinement)
니클라우스 비르트(NIKLAUS WIRTH)에 의해 제안된 하향식 설계 전략이다. 단계적 정체 는 문제를 상위의 중요 개념으로부터 하위의 개념으로 구체화시키는 분할 기법으로, 추상 화의 반복에 의해 세분화된다. 소프트웨어 기능에서부터 시작하여 점차적으로 구체화하고, 상세한 내역(알고리즘, 자료 구조)은 가능한 한 뒤로 미루어 가면서 진행한다.
임베디드 시스템, 차량 제어기의 SW 그리고 IT 등 분야별로 적합한 접근방법이 있습니다.
- 3. 정보 숨김(stepwise refinement)
정보 숨김은 필요하지 않은 정보는 접근할 수 없도록 제외하여 하나의 하위 구조 또는 하 부 시스템의 자료, 절차에 대한 구체적인 구현 내용 및 내부 정보를 다른 외부 모듈의 접 근으로부터 통제한다. 즉, 정의된 메시지에 의해서만 접근과 전달이 되도록 하는 방법으로 각 하위 구조 구현에 서로 영향을 받지 않게 설계되는 것을 의미한다. 소프트웨어 아키텍 처 설계 단계에서 채택되는 설계 전략을 세부적으로 구분하여 설계 전략에 변경이 발생하 는 경우, 그 영향이 최소한의 모듈들에만 미치도록 하는 것으로, 모듈 단위의 변경 및 시 험이 쉬우며 유지보수 시 위험에 따른 영향이 최소화되는 큰 장점이 있다. 시스템 아키텍 처 설계에서 숨겨야 할 기본 정보는 상세한 데이터 구조, 하드웨어 디바이스를 제어하는 부분, 특정한 환경에 의존하는 부분(특정한 운영 체제나 DBMS에 의존하는 부분) 및 물리 적 코드(IP 주소, 문자 코드) 등이 있다.
- 4. 모듈화(modularity)
시스템 아키텍처 모듈화는 소프트웨어를 각 기능별로 분할하는 것을 의미하며 각 기능별 로 분할한 것을 의미한다. 세부 하위 모듈은 서브루틴, 부(sub) 시스템, 소프트웨어 내의 프로그램, 작업 단위 등을 의미한다. 모듈화를 이용하여 설계하면 소프트웨어의 복잡도가 감소하고 변경이 쉬우며 프로그램 구현이 용이하고 확장성, 융통성, 경제성 등이 향상된다
(1) 모듈 속성
소프트웨어에서 모듈이란 한 프로그램의 세부적인 일부분으로 정의된다. 하나 또는 다 수의 논리적인 기능을 수행하기 위한 프로그램은 하나 이상의 독립적으로 개발된 모 듈로 구성되며 이들은 그 프로그램이 접속되기 이전까지는 결합되지 않는다.
(2) 모듈 결합도(coupling)
모듈 결합도는 모듈 간에 상호 의존하는 정도 또는 두 모듈 사이의 연관 관계(정보 교 환)를 의미한다. 모듈들 사이의 정보 교환이 많고 서로의 정보에 따라 구동되는 기능 이 많을수록 모듈들 사이의 결합도는 높아진다. 독립적인 모듈이 되기 위해서는 각 모 듈 간의 결합도가 약해야 하며 의존하는 모듈이 적어야 한다. 인터페이스가 정확히 설 정되어 있지 않거나 기능이 정확히 세분화 되어있지 않을 때 불필요한 인터페이스가 나타나 모듈 간의 의존도와 결합도가 증가한다. 결합도는 모듈의 독립성 및 응집도와 밀접한 관계를 가지고 있다. 즉, 두 모듈이 완벽 하게 기능을 수행한다면 이들은 서로 완전히 독립적이라고 할 수 있으며 서로 상호 교류가 전혀 없음을 의미한다. 결합도가 높을수록 한 모듈의 변화가 다른 모듈에도 영 향을 주며 영향이 클수록 시스템을 유지보수하기 어려워진다.
(가) 자료 결합도
자료 결합도는 모듈 간의 인터페이스가 자료 요소로만 구성된 경우의 결합도이다. 모듈이 다른 모듈을 호출하면서 데이터를 넘겨주고 호출 받은 모듈은 받은 데이터 에 대한 결과를 다시 돌려주는 방식이다. 자료 결합도는 한 모듈의 내용을 변경하 더라도 다른 모듈에는 전혀 영향을 주지 않는 결합 방식이다.
(나) 스탬프 결합도
스탬프 결합도는 모듈 간의 인터페이스로 배열이나 레코드 등의 자료 구조가 전달된 경우의 결합도이다. 모듈이 동일한 자료 구조를 조회하는 경우의 결합도이며 자 료의 구조의 변화는 그것을 조회하는 모듈 및 조회하지 않는 모듈에까지도 영향을 미치는 결합 방식이다.
(다) 제어 결합도
제어 결합도는 한 모듈에서 다른 모듈로 논리적인 흐름을 제어하는 데 사용하는 제어 요소가 전달될 때의 결합도이다. 상위 모듈이 하위 모듈의 상세한 처리 절차 를 알고 있어 이를 통제하는 경우나 처리 기능이 두 모듈에 분리되어 설계된 경우 에 발생한다.
(라) 공유 결합도
공통 결합도는 공유되는 공통 데이터 영역을 여러 모듈이 사용할 때의 결합도이다. 공통 데이터 영역의 내용을 조금만 변경하더라도 이를 사용하는 모든 모듈에 영향 을 미친다.
(마) 내용 결합도
내용 결합도는 한 모듈이 다른 모듈의 내부 기능 및 그 내부 자료를 직접 참조하 거나 수정할 때의 결합도이다. 한 모듈에서 다른 모듈의 중간으로 분기되는 경우에 도 내용 결합도에 해당된다.
(3) 모듈 응집도(cohesion)
모듈 응집도는 정보 은닉 개념을 확장한 것으로 모듈 내부에서 처리 과정 및 정보의 생성, 소비가 이루어지는 정도를 의미한다. 모듈 내부 요소들 사이의 응집도가 증가하 도록 하는 것이 바람직하며 모듈의 응집도를 높이면 모듈 사이의 낮은 결합도를 얻을 수 있다. 독립적인 모듈이 되기 위해서는 각 모듈의 응집도가 강해야 하며 응집도의 종류에는 기능적 응집도, 순차적 응집도, 교환(통신)적 응집도, 절차적 응집도, 시간적 응집도, 논리적 응집도, 우연적 응집도가 있다.
(4) 프로그램 구조(program structure)
프로그램 구조는 소프트웨어를 구성하고 있는 모듈과 모듈 간의 상호 작용 및 모듈에 의해 사용되는 자료 구조를 의미한다. 프로그램 구조는 소프트웨어의 구조 요소인 모 듈의 계층적 구성을 나타내는 것으로, 트리 구조의 다이어그램으로 표기한다.
소프트웨어 아키텍처 설계 방법
소프트웨어 설계 모형을 기술적인 관점에서 분류하면 데이터 설계(data design), 구조 설계 (architectural design), 인터페이스 설계(interface design), 절차 설계(processor design)로 구 성된다.
- 객체지향 설계 방법
객체지향 설계 기법은 구조화 설계 기법의 단점을 해결하기 위해 개발되었다. 객체지향에 서는 세상의 모든 사물을 프로세스와 데이터를 모두 갖는 객체(object)로 정의한다. 객체 는 상태, 행동 그리고 식별성이라고 하는 3개의 성질을 갖고 있으며 실세계의 사상 가능 성, 품질과 유연성의 향상, 그룹 개발의 가속화를 들 수 있다. 또 요구 분석, 설계, 프로그 래밍의 공정을 순환적으로 반복하면서 소프트웨어를 개발할 수 있다.
(1) UML(unified modeling language) 정의
UML은 소프트웨어 및 시스템 아키텍처를 모델링하는 데 사용되는 표준 비주얼 모델 링 언어이다. UML이 객체 관리 그룹(object management group, OMG,)의 표준이며 매 우 융통성 있고 사용자 정의할 수 있도록 설계된 시각적인 언어이다. 업무 프로세스, 작업 흐름, 퀴리 순서, 애플리케이션, 데이터베이스, 시스템 아키텍처 등을 이해하기 위한 모델을 포함하여 많은 종류의 모델을 시각적으로 설계할 수 있도록 해준다. UML은 프로젝트의 성공을 보장하는 것은 아니지만 많은 일들을 개선시킨다. 예를 들 어 프로젝트나 조직을 바꿀 때에 새로 교육하는 비용을 감소시킨다. 또 여러 가지 도 구나 공정, 영역 사이의 통합을 이끌어 낼 수 있다. 가장 중요한 것은, UML이 개발자 들로 하여금 업무 가치를 생산하는 데 집중할 수 있게 하고, 그것을 성취할 수 있는 패러다임을 제공한다는 데 있다.
(2) UML 다이어그램(diagram)
(가) usecase diagram
누가 어떤 용도로 시스템을 사용하는지에 대해 행위자(actor)와 사용 사례(use case) 의 관계로 표현할 수 있다.
인터넷 사이트의 회원 게시판을 usecase diagram을 사용하면 다음과 같이 표현할 수 있다. 우선 비가입자는 글을 볼 수 있는 권한을 가지며 가입자는 읽고 쓰고 삭 제하는 권한을 가진다. 또 가입자는 글쓰기에 답변쓰기 기능도 확장할 수 있다.
(나) sequence diagram
객체들의 행동을 시간의 관점에서 표현되며 객체에 실선 화살표로 그려지는 메시 지, 그리고 수직 진행 상황을 나타내는 시간으로 구성된다. sequence diagram은 아 주 단순하고 즉각적인 시각적 매력을 갖고 있기 때문에 자주 사용된다.
(다) collaboration diagram
collaboration diagram은 교류를 수행하는 객체들의 전체적인 조직과 상황(context) 에 초점을 맞춘 것이다. sequence diagram과 개념이 비슷하나 sequence diagram은 시간에 따라 배열되고, collaboration diagram은 공간에 따라 배열되어 있다. 두 객 체 사이에 메시지는 두 객체 사이의 연관선과 가깝게 화살표를 그려준다. 화살표에 는 번호가 붙는데, 이것은 메시지들의 순번을 나타내는 것이다. 또 오퍼레이션은 ‘메시지를 받는 객체로 하여금 어떤 오퍼레이션을 실행하라'는 뜻이다. 오퍼레이 션 끝의 괄호 사이에 매개변수를 삽입할 수도 있다.
(라) statechart diagram
statechart diagram은 시스템의 변화 상태를 표현한다. 즉, statechart diagram은 하 나의 객체에 집중하여 그 객체의 시작에서부터 종료까지의 상태변화를 표시하는 다이어그램이다. statechart diagram은 시스템의 모든 클래스에 대해 그릴 필요는 없으며 의미 있는 행동 양식을 보여주는 주요 클래스들에 대해서 그린다. 시작점(initial state)과 종료점(final state)이 있다. 이들은 각각 객체의 시작과 종료 의 시점을 표시해 준다. 상태 다이어그램은 위에서부터 이름, 상태변수, 활동을 나 타내는 세 영역으로 나눌 수 있다. activities는 사건(event)과 동작(action)으로 이루 어진다.
(마) activity diagram
activity diagram은 오퍼레이션이나 처리 과정이 수행되는 동안 일어나는 일들을 간 단하게 표현하기 위해 고안되었다. activity diagram은 처리 단계, 결정 위치, 분기 처리를 표현할 수 있어 업무 과정이나 오퍼레이션에서 처리되는 일 등을 효과적으로 나타내는 데 사용된다.
(바) class diagram
클래스(class)를 표현할 수 있는 양식으로 그 안에 속성(attribute)과 행위(operation) 를 포함하고 있다.
(사) component diagram
component diagram은 소프트웨어 컴포넌트의 구성과 연결 상태를 나타낸다. 소프 트웨어 컴포넌트는 시스템을 이루는 물리적 요소이다. 그 예로서는 데이터 파일, 실행 파일, 도큐먼트 등이 있다. 여기서 컴포넌트는 ‘클래스를 소프트웨어로 구현 한 것’으로 간단히 정의 내릴 수 있다.
(아) deployment diagram
deployment diagram은 시스템의 소프트웨어와 하드웨어 컴포넌트 간의 물리적 관 계를 표현한다.
'Robotics : 로봇공학 > Certificate : 자격증' 카테고리의 다른 글
| 1. 요구 사항 파악 및 작업 분석하기 - 1-2. 작업 및 운용 환경 분석 (0) | 2023.02.07 |
|---|---|
| 1. 요구 사항 파악 및 작업 분석하기 - 1-1. 요구 사항 파악 (0) | 2023.02.05 |
| 2-1-3 로봇 소프트웨어 계측 구조, 미들웨어 구현 위한 운영체제 설치 (3) | 2023.02.02 |
| Middleware, Operating system : 2-1-1 미들웨어, 로봇 운영 체제 (0) | 2023.01.26 |
| 로봇SW기사 - 정리 현황 2023 (7) | 2023.01.26 |
