이 포스팅 시리즈는 수업 때 쓰는 레퍼런스 Bernd Bruegge and Allen Dutiot의 "Object-Oriented Software Engineering Using UML, Patterns, and Java: Pearson New Interenational Edition PDF"를 바탕으로 정리하였다. (영/한 혹은 영문)
목차
1. Introduction to Software Engineering
2. Modeling with UML
3. Project Organisation and Communication
4. Requirements Elicitation
5. Analysis
6. System Design: Decomposing the System
7. System Design: Addressing Design Goals
8. Object Design: Reusing Pattern Solutions
9. Object Design: Specifying Interfaces
10. Mapping Models to Code
11. Testing
12. Rationale Management
13. Configuration Management
14. Project Managment
15. Software Life Cycle
16. Methodologies: Putting It All Together
잘 만들어진 소프트웨어 시스템은 복잡하고 사용자의 요구사항과 목표한 환경에 맞게끔 발전시켜 가야 한다. 이 책에서는 복잡하고 계속 변하는 소프트웨어 시스템을 다루기 위해 Object-oriented techniques (객체지향 테크닉)을 소개한다.
1.1 소프트웨어 엔지니어링에서 실패가 일어나는 이유
- Algorithmic fault: 잘못된 알고리즘
- Bad communication between teams: 팀 내의 소통 문제
- Wrong usage of the tools (compass): 잘못된 툴의 사용
- Incorrect interface specification: 잘못된 인터페이스 사양
- Wrong subsystem decomposition: 잘못된 하위 시스템 분류
- Physical impossibility: 물리적 불가능 상태
소프트웨어 시스템은 다양한 요소로 구성되어 있는데, 이 요소들은 그것 자체만으로도 복잡할 뿐만 아니라 개발 단계에서 다양한 관계자들이 협업하기 때문에 더 복잡해진다. 게다가 그 안에서 각자가 추구하는 목표가 다르고, 수 년에 걸쳐 개발이 이루어지기 때문에 우리가 단 번에 이해하기란 쉽지 않다. 또한 프로젝트는 계속해서 변한다. 요구사항이 복잡하고, 에러가 생기면 해결하거나 개발자가 더 좋은 방법을 찾아내면 업데이트를 진행해야 한다. 프로젝트 기간이 길어질 경우 프로젝트에 새로 참여하는 멤버가 인수인계를 잘 받거나 걸맞은 트레이닝이 수반되어야 한다. 프로젝트 매니저는 이러한 변화에 대비해 많은 가정들과 시나리오를 만들어야 하고 불필요한 시스템이 있다면 빼야 한다.
1.2 소프트웨어 엔지니어링이란?
소프트웨어 엔지니어링을 아주 간단하게 말하자면,
1. 고객이 원하는 시스템의 범위와 요구사항에 대해 충분히 상의하고, (Communication)
2. 복잡한 문제를 작은 조각들로 쪼개어 해결한다.
3. 쪼개어 해결된 문제를 다시 큰 원래의 시스템으로 합친다. (Integration)
4. 중간중간 수정한다.
결국 소프트웨어 엔지니어링은 problem-solving activity, 솔루션을 찾는 것이다. 그러기 위해서 문제를 이해하고 분석해 더 작은 문제들로 나누고, 그 문제들을 다시 큰 구조로 합칠 수 있는 능력이 요구된다. 이를 위해서는 Techniques, methodologies, tools 가 필요하다.
- Techniques: 결과를 도출하기 위한 일련의 과정을 잘 표기하는 것과 같다. 예) 요리할 때 레시피, 높은 가격 순서대로 정렬하는 알고리즘 등
- Methodologies : 소프트웨어 전반에 걸쳐서 적용될 알고리즘과 같은 테크닉의 모음이다. 예) 다양한 레시피를 엮은 요리책, 객체지향형 디자인
- Tools : 알고리즘을 짜기 위해 사용되는 도구이다. 예) 오븐, 컴파일러, 디버거, 에디터, IDE 등
소프트웨어 엔지니어링을 단순히 코딩만 하는 것으로 알기 쉬운데, 문제 해결과 모델링, 계속적인 수정이 요구된다. 해결할 과제를 이해했다면, 엔지니어는 한 번에 한 가지 디테일에만 집중해 모델링 함으로써 복잡한 전체 시스템을 세분화해 구축한다.
모델링이란,
너무 크거나 작거나 복잡하거나 비용이 많이 들거나 존재하지 않는 것을 시각적으로 단순하게 표현해 냄으로써 시스템에 대한 이해를 돕도록 하는 것이다. 예를 들어, 공룡 뼈를 발굴하고 조각조각을 맞춰 봄으로써 우리는 현재 존재하지 않는 공룡의 모습을 해부학적 구조에 기반해 시각적으로 유추해낼 수 있다. 뼈, 치아, 발톱 조각들이 많이 발견되면 될수록 더 실제와 유사하게 모델링을 할 수 있다.
여기서 공룡은 우리가 만들고자 하는 System, 포유류의 해부학적 구조는 application domain model이 된다. 어떤 양상과 패턴을 가지고 문제를 해결할 건지에 대한 설명이라고 보면 된다.
소프트웨어 엔지니어도 비슷한 과제에 직면한다. 기차역 제어 시스템을 예시로 들어보자. 기차가 역에서 출발하고 도착할 때 어떤 트랙을 이용할지, 트랙 신호등은 어떻게 운영되는지에 대한 기본 지식이 있어야 시스템을 만들 수 있다. 주식거래소 시스템을 만들기 위해서는 기본적으로 주식이 사고 팔리는 거래 방식을 알아야 만들 수 있다.
이렇듯 엔지니어가 모든 전문 지식을 알 필요는 없지만 시스템에 연계되는 application domain의 콘셉트 정도는 알아야 모델을 만들 수 있다. 이때, 시스템 전체를 한 번에 구축하기에는 너무 크고, 복잡하고 비용이 많이 들기 때문에 소프트웨어 엔지니어들은 solution domain model 을 만든다. 객체지향 방식은 application domain과 solution domain 모델링을 하나로 합친다. 더 자세한 모델링 방법에 대해서는 다음 포스팅에서 알아보도록 하겠다.
댓글