노는 게 제일 좋아

이번에는 사용자 인터페이스 설계를 배울 것이다. 그냥 인터페이스가 아니라 사용자 인터페이스임을 알고 알아보자 사실 우리는 소프트웨어의 개발을 프로그램을 동작을 위해 만든 것이다. 사람이 하는 일을 프로그램이 하게 하려는 것이 소프트웨어 개발의 주목적이었다. 그 분야도 사실 주로 과학 분야나 군사 분야 여서 사용자 인터페이스가 사실 필요가 없었다. 그렇지만 컴퓨터가 대중들에게 보급되고 일상생활에서 컴퓨터가 쓰이다 보니까 사용자의 인터페이스를 고려해야 했다. 컴퓨터가 적용되는 분야도 다양해졌고 사용하는 방식도 일괄처리에서 다양한 형태로 바뀌었다. 다시 말해서 사용자의 입장이 어느 시대보다 중요해진 시기가 되었다. **모든 소프트웨어는 사용자의 만족이 큰 목적이 됨 ++소프트웨어 시스템에 있어서 사용자의 만족..

앞에 글에서 말했던 것처럼 그림을 하나 공부하려고 한다. 또 재사용에 대해서 배우려고 한다. 해보자 우선 클래스를 이해해야 설계를 잘할 수 있다. 다시 말해서 객체가 가지는 상태와 여러 오퍼레이션 사이의 관계, 여러 오퍼레이션들이 서로 작용하는 효과를 이해해야 한다. ++분석 모델이 나타내는 선언적인 정의만으로는 이해하기 힘들다 그래서 다이어그램, 그림을 그려봐야 한다. 상태 다이어그램은 상태와 어떤 이벤트가 발생했을 때 이루어지는 상태 사이의 변환으로 구성된다. 여기서 객체를 모델링 할 때 상태는 속성값이며 이벤트는 객체에 대하여 오퍼레이션이 수행됨을 나타낸다. 어떤 이벤트가 발생하였을 때 상태가 어떻게 변하는지를 나타내면 이벤트와 상태의 관계를 정의할 수 있다. **객체의 상태를 모델링할 때 주의할 ..

클래스의 인터페이스를 이번엔 정의해보려고 한다. 그렇다면 왜 중요한지부터 알아봐야겠지? 알아보자 우선 3가지 정도의 관점이 있는데 1. 클래스 구현 2. 클래스 사용 3. 클래스 확장 차례로 살펴보자 1. 클래스 구현 클래스 설계를 보고 프로그래밍 하는 개발자의 관점이다. 클래스 내부 자료구조와 각 오퍼레이션의 프로토타입을 중요하게 생각한다. 2. 클래스 사용 클래스를 이용하는 다른 클래스를 개발하는 입장에서는 클래스가 제공하는 오퍼레이션 다시 말해서 public으로 선언된 오퍼레이션에 관심이 있다. 클래스를 사용할 때 클래스가 제공하는 서비스는 무엇이며 어떻게 호출하고 지켜야 할 약속이 무엇인가인지 알아보는 것이다. 3. 클래스 확장 클래스를 확장하는 관점은 개발자의 특수한 관점인데 얘도 public ..

클래스는 앞서 많은 글들에서 다루어왔고 여기서 말하는 클래스 설계라는 것은 분석 단계에서 아직 확정되지 않은 클래스 내부 부분 중 구현에 필요한 중요한 사항을 결정하는 작업을 말한다. **즉 클래스 추출 및 클래스 간 관계 분석이다. 본격적으로 알아보자 클래스 설계는 각 클래스 내부에 초점을 두어 소속된 객체의 상태가 오퍼레이션의 호출에 따라 어떻게 변하는지를 잘 봐야한다. 다시 말해서 상태와 오퍼레이션의 관계를 잘 봐야한다는 것이다. **왜냐하면 클래스가 가지는 속성 값에 따라 오퍼레이션 구현이 달라지니까!! 그래서 객체의 상태 변화 모델링 필수라고 할 수 있다. **상태 의존적인 클래스를 구현하기 전에 먼저 객체 상태 변화에 대한 모델링은 필수적이다. 클래스 설계에 대한 몇 가지 가이드라인을 살펴보려..

소프트웨어 설계이 이유는 소프트웨어 솔루션을 위한 문제 해결과 계획 과정이라고 할 수 있다. 하지만 큰 그림만 그려서는 완성이 안된다. 이제 디테일, 세부사항에 대해 들어가보자 아키텍쳐 설계 단계에서는 추상 수준은 높다 그렇지만 모듈 추상 수준은 조금 낮다. 상세 설계에서는 추상 갭을 메우기 위하여 클래스 인터페이스와 내부에 대한 설계, 영구적 데이터에 대한 설계 작업이 필요하다. 그런데 위에 제목에서 말했듯이 디자인 패턴, 즉 어떤 패러다임을 사용하느냐에 따라 상세 설계가 많이 달라진다 ++ 우리는 2가지를 배웠다. 구조적 방법, 객체지향 방법 1.구조적 방법 프로시저 안의 로직 (알고리즘) 설계 2. 객체지향 방법 클래스 안의 메소드 설계 // 이미 글을 처음부터 봤으면 다 알 것이다. 소프트웨어 시..

이번에는 미들웨어를 알아보자 미들웨어 딱 들으면 뭔가 중간에 있는 ?? 그런 느낌이 난다 진짜인지 아닌지 알아보자 소프트웨어 아키텍쳐는 빌딩 아키텍쳐와 비슷하다고 말하곤 하는데 빌딩을 설계할 때 여러 각도에서 설계도를 작성하고 빌딩의 구조와 기하학 및 특성을 나타내도록 한다. 다시 말해서 설계는 요구를 기초로 건축 공간, 기능, 미학적 또는 기능적 품질 , 예산을 고려해서 표현한다. 설계도를 이제 정말 시공회사가 건축할 수 있을 정도로 바꾸려면 더 많은 작업이 필요한데 예를 들어서 벽, 바닥 레이아웃, 계단, 전기 시스템, 수도 등등 추가로 설계할 것들이 엄청나게 많다. 위에 설명을 왜 했느냐??? 다 미들웨어를 설명하기 위해서 했다. 미들웨어를 건축에 비유하자면 배관이나 배선에 해당하는 부분이라고 할 ..

6가지는 이전 글에서 설명했으니 첫 번째 부터 차차 살펴볼까? 계층 구조 스타일 그림을 보면 살짝 감이 오겠지만 고전적인 방법으로 각 서브시스템이 하나의 계층이 되어 하위층이 제공하는 서비스를 상위층의 서브시스템이 사용하도록 구성된다. 즉 상위층은 클라이언트가 되며 하위층이 서버처럼 작동하고 미리 정의된 API를 이용하여 상호작용을 한다. ++N-tier 아키텍쳐 스타일은 각 층을 보다 개선된 버전으로 교체할 수 있다. 예를 들어 시스템을 여러 플랫폼에 이식할 때 사용자 인터페이스 층을 교체할 수 있다. (물론 어떤 층의 교체가 하위층에 영향을 주어서는 안된다.) ++N -tier 아키텍쳐 스타일은 대화형 시스템을 위한 스타일로 자주 사용된다. (꼭 대화형 시스템만을 위한 것은 아니다. 대부분 운영체제가..

오늘은 설계과정 살짝 맛만보자 소프트웨어 시스템의 아키텍쳐 설계 과정은 의사 결정 과정이면서 동시에 인지적인 과정이란다. 시스템의 타입이 아키텍쳐 스타일에 큰 영향을 주는데 그래서 내가 무엇을 만드는지, 목적이 무엇인지 설계하면서 방향성을 잃지 않아야 한다. 아키텍쳐 설계는 반복적인 과정이다. **시스템이 서브 시스템으로 구성되어 있고 그 서브 시스템은 컴포넌트나 다른 서브 시스템으로 구성되어있으니까. 그림을 보고 이해해보자 ,아키텍쳐 설계과정이다. 말로 한 번 더 설명해보자면 Step 1. 목표를 설정한다. 전체 시스템에 대한 설계 목표가 파악되고 결정되어야 한다. Step 2. 시스템의 타입을 결정한다. 시스템이나 서브시스템의 타입을 결정한다. // 그래야 스타일 결정하지 Step 3. 아키텍처 스타..

이번엔 설계 원리에 대해서 다뤄보도록 하겠씁니다. 우선 설계에 근거하여 구축한 시스템이 요구를 잘 만족하였을 때 그 설계가 바르다고 할 수 있다. 설계 작업의 목표는 시스템을 위하여 설계 하나를 만드는 것이 아니라 시스템을 개발하는 조건이나 운용될 환경 조건의 제약 안에서 가능한 여러 설계 중에서 최적의 설계안을 발견하는 것이다. 그렇게 하려면 설계를 평가할 수 있는 특성과 기준을 정해야 하는데 사실 정량적으로 평가할 수 있는 것이 가장 좋지만 소프트웨어 특성상 정량적 평가가 어렵다. 그래서 다른 2가지를 평가하는데 그것이 바로 1. 효율성(efficiency) 시스템이 사용하는 자원이 적정하고 효과적임을 의미한다. 2. 단순성(simplicity) 이해하기 쉬운 설계를 작성하는 것, 즉 유지보수성에 직..

이번에는 아키텍쳐라는 것을 배워보자. 아키텍쳐는 (architecture) 해석하면 알 수 있듯이 무슨 구조인가?? 즉, 뼈대 같은 것들을 말할 것 같다?? 배워보자 우리는 앞서 요구 분석 작업을 했다. 그 요구 분석 작업을 통하여 무엇을 개발할 지 결정했고 그 이후에 도메인 영역의 문제에 집중해서 모델링 했다. 설계 단계로 넘어가면서 솔루션 영역의 과제들 예를 들어 소프트웨어의 내부 구조, 자료와 사용자 인터페이스를 어떻게 만들 것인지 정해야 한다. 다시 말해서 요구 분석 명세서에 기술된 기능을 여러가지 제한 요건에 맞도록 설계하는 일이 필요하다 건축 설계를 예로 들었지만 소프트웨어 설계도 마찬가지다. ** 설계는 일반적으로 창조작인 작업이라고 할 수 있다 ++ 그렇다고 체계적인 접근이 없는 것은 아니..