다형성(Polymorphism) 예제 Deer 클래스 Deer 클래스를 아래와 같이 정의해보자. ▼ class Deer { private: char name[10]; // 사슴 이름 int age; // 사슴 나이 double weight; // 사슴 무게 double height; // 사슴 키 public: Deer(const char* name, int age, double weight, double height, double antlersLength); // 생성자 char* getDeerName() const; // 사슴 이름 getter int getDeerAge() const; // 사슴 나이 getter double getDeerWeight() const; // 사슴 몸무게 getter d..

객체 지향 프로그래밍 (Object-Orientation Programming) 지금까지 배운 객체지향 프로그래밍은 대체로 C++ 문법에 대한 내용, 그 중에서도 상속에 대한 C++ 문법이었다. C++ 뿐만 아니라 JAVA와 같은 대표적인 OOP 프로그래밍 문법들도 배웠을 것이다. 그러나 이번에는 문법을 배우는 것이 아니라, 실제 소프트웨어 개발에 어떻게 적용되는지를 배울 것이다. 소프트웨어를 개발하는 이상적인 방법 인터페이스 컴퓨터(하드웨어)를 생각해보자. 컴퓨터를 한 회사에서 처음부터 끝까지 다 만들지는 않는다. 삼성에서 만든 컴퓨터의 스펙을 보면 아래와 같지만, 이 모든 부품을 삼성에서 다 만든 것이 아니다. 다른 회사들이 만든걸 모아서 만든 것이다. 그런데 굉장히 신기하게도 각 부품들을 다 다른 ..

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

요구사항 포착 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, 다른 하나..

소프트웨어란? 소프트웨어라는 말을 들으면 처음 드는 생각은 작성한 코드, 컴파일한 바이너리 코드, exe 파일, app 등등을 먼저 생각하곤 한다. 그것들도 소프트웨어이긴 하나 그것만이 소프트웨어인 것은 아니다. 조금 더 넓은 의미로 아래의 것들도 소프트웨어로 볼 수 있다. Computer Programs 우리가 보통 생각하는 프로그램들이다. 작성한 코드, 컴파일한 바이너리 코드, exe 파일, app 등등이 있다. Configuration Files Configuration file은 코드에는 포함되지 않지만 프로그램을 구동할 때 필요로 하는 파일을 말한다. OS의 경우에는 OS가 구동될 때 사용하기 위해 따로 파일로 설정해놓은 값들이 Configuration File이라고 할 수 있다. System ..