개요 System Call 이란? System Call은 운영 체제의 커널이 제공하는 서비스에 대해, 응용 프로그램의 요청에 따라 커널에 접근하기 위한 인터페이스이다. 정말 간단하게 다시 말하자면, System Call은 커널에 접근하기 위한 수단 혹은 도구 이다. 그렇다면 우리는 커널에 왜 접근해야하는지를, 그리고 커널에 접근하는 수단과 도구가 따로 만들어진 이유를 알면 System Call에 대해 이해할 수 있다는 것이다. System Call이 필요한 이유 커널에 왜 접근해야할까? 우리가 일반적으로 쓰는 프로그램들은 OS, 시스템의 힘을 빌려서 만들어진다. 유저 레벨의 함수들로는 고차원적인 동작을 하는 프로그램을 만드는게 사실상 불가능하다. 그렇기에 커널(kernel)의 도움을 반드시 받아야 한다...

운영체제의 구조 운영체제의 구조는 아래의 부품들의 구조와 유사하다. 운영체제의 역할이 바로 이 하드웨어들을 다루는 것이기 때문이다. ▼ 그렇기에 각 하드웨어들의 입장에서 운영체제를 볼 수 있다. 각 하드웨어들의 입장에서 본 운영체제가 바로 운영체제가 하는 일이라고 볼 수 있다. CPU의 입장 CPU는 일을 처리하는 핵심 부품이다. 그렇다면 일을 어떤 순서로 처리해야 효율적이고 공평할까? 사회의 시선으로 보면 먼저 들어온 일 부터 처리하는게 공평하지만, 효율적이라고는 하기 힘들다. 은행업무를 예시로 보자. ▼ 사회의 관점에서는 먼저 온 사람부터 업무를 봐주는게 공평하고 당연한 처사다. 번호표를 뽑았으니까 말이다. 그런데 먼저 온 사람의 업무가 2시간이 걸린다면 그건 조금 낭패다. ▼ 뒤의 사람들은 기껏해야..

개요 요구사항과 관련해서 단순히 전부 적고 끝내는 것이 아니라, 어떤 요구 사항이 언제 들어왔고 사라졌는지에 관한 세부적인 내용도 관리를 해야한다. 기능 요구사항(Functional requirements)으로는 use case diagrams를, 모든 유형의 요구사항(All types of requirements)으로는 separate requirement lists를 작성하면 된다. 위의 두 작업까지 하면 specification이 끝나고 design을 할 차례가 된다. Use Case Diagram 그리기 Use Case Diagram을 처음 보면 상당히 복잡한 형태로 그려져 있다고 느껴진다. 마치 시스템이 내부적으로 어떻게 돌아가는지 까지 다 그린 것 같은 느낌이지만, Use Case Diagra..

운영체제(Operating System) 운영체제란? 운영체제란 컴퓨터 하드웨어 바로 위에 설치되어 사용자 및 다른 모든 소프트웨어와 하드웨어를 연결하는 소프트웨어 계층을 말한다.▼ 좁은 의미로는 커널이라고 말하고, 넓은 의미로는 커널뿐만 아니라 각종 주변 시스템 유틸리티를 포함한 개념을 말한다. 운영체제의 목적 운영체제의 목적은 크게 아래의 4가지가 있다. 컴퓨터 시스템의 자원을 효율적으로 관리 프로세서, 기억장치, 입출력 장치 등의 효율적 관리 사용자 및 운영체제 자신의 보호 프로세스, 파일, 메세지 등을 관리 컴퓨터 시스템의 자원들은 실행 도중에 추가되는 것들이 아니라 시작 전에 정해진 것들이다.▼ 메모리나 저장공간, 그리고 CPU의 성능까지 컴퓨터가 켜져있는 동안에는 바뀌지 않는다. 위에 운영체제..

요구사항 포착 Requirements를 다른 말로 specification이라고도 할 수 있다. 요구 사항을 들어준 것이 소프트웨어의 기능과 마찬가지이기 때문이다. 그렇기에 requirements를 정의하고 들어가는 것은 굉장히 중요하다. 그럼 requirements는 어떻게 찾을 수 있을까? 1. 단체가 현재 어떻게 돌아가고 있는지 이해해야 한다. 학교 관련 시스템을 개발한다고 해보자. 학교와 관련된 시스템을 만들기 위해서는 어떻게 돌아가는지를 알아야 하는데, 단순히 어떻게 돌아가겠지 하고 상상하는 것으로 학교가 어떻게 운영되고 있는지 알 수 없다. 직접 가서 학교가 어떻게 운영되고 있는지를 확인해봐야한다.▼ 2. 현재 시스템의 문제점이 무엇일까? 문제점이 없는데 개선할 필요가 있을까? 새로운 기능, ..

모델(Model)이란? 어플리케이션 영역에서 실존하는 것이나 상상의 것들을 표현하는 것을 모델이라고 한다. 예를 들면, 교각, 교통흐름, 건물, 경제 정책 등등을 모델이라 할 수 있다. 소프트웨어 측면에서는 Abstraction(추상화)을 말한다. Abstraction을 추상화라고 알고 있지만, 필요로 하는 것만 추출하는 것이라고 이해하는게 더 좋다. 학생들을 예로 보자. 우리는 실존하는 학생들이고, 개개인의 셀수 없이 많은 특성이 있다. 그런데 학교 시스템에서는 우리를 학번, 이름 등등의 처리하기 편한 정보로 우리를 특정화시킨다. 이렇게 컴퓨터로 가져오면서 공통적인, 대표적인 특징으로 표현한다. 또한 특정 요소 전부를 한 번에 표현하면 보기도 이해하기도 어렵기 때문에 계층적으로 표현하기도 한다. Dia..

Agile 모델 그 전까지는 실제 현장에서 사용할 수 있는 모델들과 워터폴과의 차이점을 이야기 했다. 원래 Agile 개발 방법은 책의 9판까지는 없었다고 한다. 10판에 새롭게 추가된 내용인데, 여기서 알 수 있는 점은 Agile 방법을 최근에 많이 쓰게 됐다는 것이다. 등장 배경 Waterfall 방식의 장점이자 아이덴티티는 매 단계가 끝이 나면 문서가 나온다는 것이다. 하지만 문서 제작에 의한 오버헤드가 꽤나 컸다. 매 단계가 끝이 나면 문서가 나오는 것은 좋지만 그 장점을 위한 오버헤드가 생각보다 많이 컸기에 이 오버헤드를 줄이는 Agile 방식을 고안하게 되었다. 목표 Agile 모델의 목표는 요구사항 변경에 빠르게 반응하여 delivery time을 줄이는게 목표다. Agile이라는 단어의 뜻..

Process Iteration Process Iteration은 뜻 그대로 해석하면 프로세스 반복을 말한다. 하지만 여기서 말하는 프로세스는 Process Activites 포스트에서 말한 5가지 Activities다. "전에 말한 Activity들을 수행하는 것은 납득이 가는데, 왜 이 Activity들을 반복 하는 것일까?" 그 이유는 소프트웨어 개발하는 동안 요구사항 변화는 불가피하기 때문이다. 아래의 이유들로 바뀌곤 한다. 비지니스의 변경 비지니스의 변경으로 인해 필요로 하는 요구 사항의 기능들이 바뀔 수 있다. 구현을 위한 새로운 기술의 등장 이런 새로운 기술들은 구현을 쉽게 만들어주어 새로운 가능성을 열 수 있다. 하지만 이런 기술들을 섣불리 도입했다가 큰 결함이 생길 수 있어 조심해야한다...

Process Activities 소프트웨어 개발 단계는 소프트웨어 공학 게시글에서도 다룬, Specification Design and implementaion Validation(Testing) Evolution(Maintenance) 의 4 단계가 있다. 이들은 개발 방식에 따라 조금씩 다르게 구성되곤 하는데, waterfall 방식에서는 일련의 과정으로 구성되지만, incremental development에서는 개별적인 과정으로 구성된다. Software Specification 소프트웨어의 요구 사항들을 결정하는 것을 말한다. 요구 사항으로는 해당 프로그램에서 꼭 있어야하는 필요 기능과, 프로그램 개발에 있는 제약 사항들이 있을 것이다. 소프트웨어 개발에 들어가기 전에 정확히 무엇을 만들어야하..

소프트웨어 프로세스 모델이란 소프트웨어 프로세스 이전 포스트에서도 다루었지만 다시 이야기를 하자면, 소프트웨어 프로세스는 소프트웨어 시스템을 개발하기 위해 필요한 구조화된 활동들의 집합이다. 여러가지 종류의 소프트웨어 프로세스가 있지만 모두 아래의 요소들을 포함하고 있다. Specification Design and Implementation (Development) Validation (Testing) Evolution (Maintenance) 소프트웨어 프로세스 모델 소프트웨어 프로세스 모델은 어떤 프로세스의 대표적인 형태라고 할 수 있다. Plan-driven processes VS Agile processes 프로세스 모델에는 크게 두가지 형태가 존재한다. 하나는 Plan-driven, 다른 하나..