검색결과 리스트
architecture에 해당되는 글 2건
- 2011.03.08 2011.03.08.Tues 아키텍처 발전역사
- 2010.12.13 [OOAD] 아키텍처, IA , 화면기준안, 스토리보드 (1)
글
2011.03.08.Tues 아키텍처 발전역사
1. standalone
하나의 컴퓨터에 (프로그램의) 절차와 데이터가 모두 존재한다.
2. 2-Tier
다수의 공유가 가능하게 되었지만, 다수의 사람들이 동일한 데이터에 접근하여 수정하여 되면, 데이터가 망가지게 된다.
그래서 DataBase를 관리하는 시스템인 DBMS(DataBase Management System)을 두어, 동시 사용자들간에도 데이터를 이상없이
(무결성) 다룰 수 있도록 한다. (Data+Base는 Data를 저장하고 있는 기지라는 의미를 갖는다. )
유지보수의 관점에서는 엄청난 비용이 드는 문제점이다. 문제의 원인은 변경의 대상이 되는 절차가 모두 클라이언트 내에
존재하기 때문이다. (비지니스 로직을 포함하는 이런형태의 클라이언트를 Fat 클라이언트라 한다.)
이 문제를 어떻게 해결하였을까? 다음 세대의 아키텍처를 알아보자.
3. 2-Tier + Procedure
Procedure 라고 하며, 대부분의 현대 DBMS 에 지원하고 있다. 클라이언트는 처리로직을 가지고 있지 않으며, 단지
Database에 접근하기 위한 인터페이스로서만 동작하게 되며 이런 형태를 Thin 클라이언트라 한다.
(초창기 데이터베이스 시장은 Informix가 선점하고 있었으나, Oracle 이 Procedure를 통해 시장 주도권을 장악할 수 있었다.)
절차와 데이터가 함께 있는 형태는 장점이자 시스템의 속도를 너무 느리게 하는 단점으로 작용하였다. 이 문제를 어떻게
어떻게 해결하였을까? 다음세대의 아키텍처를 알아보자.
4. 3-Tier
이후에는 다수의 AS 노드와 DataBase 노드를 클러스터링하여 병렬시스템으로 구축한 소위 N-Tier 아키텍처가 유지된다.
5. 아키텍처의 발전역사
지금까지 알아본 아키텍처의 발전역사를 전체흐름은 아래 그림과 같다.
(정반합이란 헤겔의 변증법을 도식화한 논리전개 방식의 하나)
분리하여 해결하였다. 하지만 공유의 문제는 해결했지만, 유지보수성 문제가 발생하였다. 해결책으로 분리된 절차를
데이터베이스의 Procedure 형태로 결합하여 해결하였다. 하지만, 인터넷의 등장과 수많은 사용자들의 발생으로 데이터와
절차의 결합은 다시 성능의 문제를 가져왔고, 절차를 AS(Application Server)로 분리하여 이 문제를 해결하였다.
이상과 같이 아키텍처의 역사를 절차와 데이터의 관점에서 정반합의 연속으로 바라보면 이해하기 쉬워진다.
컴퓨터의 신호전달 과정
(이진수를 사용한 정보전달의 시초)
통해 모니터로 전달이 된다. (모니터에선 다시 디지털로 변경하여 최종출력을 할것이다.)
HAL과 Driver
제어할 수 있는 정보를 알고 있어야 한다. 하지만 수많은 하드웨어 정보를 운영체제가 포함하기에는 정보량이 너무 많아지게
된다. 그래서 HAL이라는 추상화 계층을 두어 운영체제는 특정 하드웨어에 종속적이지 않는 명령으로 하드웨어와 통신하려
한다. 각 하드웨어 제조사들이 제공하는 HW 제어정보를 담은 Driver는 이 HAL 계층에 결합 되어 실제적으로 하드웨어를
제어하는 나머지 퍼즐조각으로서 기능한다. kenerl 입장에서는 HAL로 인해 어떤 하드웨어를 사용하는지 모르고도, 미리
정해진 표준화된 규칙을 통해 하드웨어를 제어할 수 있게된다.
정리하느냐에 따라 문제해결을 빨리 할 수도, 느리게 할 수도 있다. 즉 자료구조란 문제를 빨리 해결하기 위해 데이터를
정리하는 방법이라 할 수 있다. 데이터란 절차 안에서만 그 의미를 갖기 때문에 절차로서의 알고리즘과 데이터로서의
자료구조는 뗄수야 뗄수 없는 관계에 있다.
'방법론로그 > OOAD' 카테고리의 다른 글
| 방법론(methodology) (0) | 2011.04.12 |
|---|---|
| 2011.03.08.Tues 아키텍처 발전역사 (0) | 2011.03.08 |
| [OOAD] 요구사항 수집부터 분석까지 (0) | 2010.12.13 |
| [OOAD] 아키텍처, IA , 화면기준안, 스토리보드 (1) | 2010.12.13 |
설정
트랙백
댓글
글
[OOAD] 아키텍처, IA , 화면기준안, 스토리보드
이 포스트에서는 아키텍처와 UI 디자인 단계의 산출물에 대해서 간략하게 알아볼 것이다..
아키텍처가 결정됨과 동시에 Programming 설계와 더블어 UI 설계를 시작하게 된다. UI 설계 단계의 산출물에는
IA, 화면기준안, 스토리 보드가 존재한다. 이들 하나하나에 대해서만 알아볼 것이며, 이것들을 하나의 흐름으로
연관지어 설명하지는 않겠다. 이런것들이 무언인지만 파악하고, 추후 포스트에서 전체적인 흐름을 설명하겠다.
1. 아키텍처(Architecture)
성능과 안정성 등과 같은 비기능적인 요구사항을 만족시키 위한 것으로, 시스템의 S/W 및 H/W 의 전반적인 구성을 포함한다.
흔히 stand alone, 2-tier , 3-tier, 혹은 웹 아키텍쳐, 애플리케이션 아키텍처 등과 특정 목적을 달성하기 위해 최적화된 소프트웨어
및 하드웨어의 구성을 의미한다.
stand alone : 단일 PC에서 동작하는 구성
2-Tier : client와 데이터 및 그것을 처리하는 비지니스 로직을 갖는 DB, 2개 층으로 구성되는 시스템
3-Tier : 비지니로직를 갖는 DB에 대한 부하를 분산하기 위해, 비지니스 로직을 WAS(Web Application Server)에 별도로 분리해 3개층으로 구성되는 시스템 형태. 여러 대의 WAS 를 마치 하나처럼 클러스터링하여 부하를 분담한다
웹 아키텍쳐: 시스템의 접근이 웹으로 이루어지는 구성
애플리케이션 아키텍처: 시스템의 접근이 애플리케이션을 통해 이루어지는 구성
엔터프라이즈 아키텍처 : 시스템의 접근이 웹과 애플리케이션을 통해 이루어지는 구성
2. IA(Information Architecture)
인간이 소프트웨어를 이용하여 정보, 즉 Contents와의 접점에서 사용자가 편리하게 고민하지 않고 정보를 찾아 지식을 얻어
갈 수 있도록 정보를 배치하는 과정
3. UI 기준안
4. 스토리보드(Story Board)
5. 그 외 용어
1) EJB(Enterprise Java Beans)
네트웍 커넥션 자원(Dao)과, 비지니스를 로직을 갖는 컨트롤러(Manager)와 같은 객체자원을 원격에서 대신 관리해주는
엔터프라이즈 서버 프레임웍.
네트웍 커넥션은 Entity Bean, 비지니스 로직 컨트롤러는 Sesssion Bean으로 관리된다
2) Fail Over
프로세서, 서버, 네트웍 또는 데이베이스 등이 고장, 또는 유지보수시 시스템이 중단되는 것을 막기위하여
두 개의 이상의 시스템을 중복 구축하고, 고장, 유지보수 하는 1차 시스템의 기능을 그대로 2차 시스템이 수행하는 구조
(사용자에겐 아무일도 없었다는 듯이 인식된다)
3) RAC (Real Application Cluster)
여러대의 병렬 DB들을 마치 하나의 DB인 것처럼 사용할 수 있는 오라클 DB 클러스터링 기법
데이터베이스의 확장성과 성능향상의 장점이 있다.
'방법론로그 > OOAD' 카테고리의 다른 글
| 방법론(methodology) (0) | 2011.04.12 |
|---|---|
| 2011.03.08.Tues 아키텍처 발전역사 (0) | 2011.03.08 |
| [OOAD] 요구사항 수집부터 분석까지 (0) | 2010.12.13 |
| [OOAD] 아키텍처, IA , 화면기준안, 스토리보드 (1) | 2010.12.13 |
