구조적 방법론
정형화된 분석 절차에 따라 사용자 요구사항을 파악하여 문서화하는 처리중심의 방법론이다.
빠르고 간단한 프로세스의 방법론이지만, 프로젝트 도중 발생할 리스크 관리의 부재나 변수에 취약한 특징 때문에 소규모의 단위 프로젝트에서 채택한다.
타당성 검토 → 계획 → 요구사항 분석 → 설계 → 구현 → 테스트 → 유지보수
정보공학 방법론
정보 시스템의 개발을 위해 계획 분석, 설계, 구축에 정형화된 기법들을 상호 연관성 있게 통합 및 적용하는 데이터 중심의 방법론이다.
이 방법론은 데이터 중심적인 특징을 가지고 있는데, 수시로 변하는 업무 프로세스와 달리 데이터는 잘 변하지 않으므로 시스템 유지보수를 줄이고 잦은 변화에 적극 대응하고자 하는 목적이다. 프로세스와 데이터를 분리하여 분석 및 설계를 진행하되 상관분석을 통해 상호 검증한다.
객체지향 방법론
현실세계의 개체(Entity)를 기계부품처럼 하나의 객체(Object)로 모델링하여 부품을 조립하듯이 소프트웨어를 구현하는 방법론
객체지향의 특성은 다음과 같다.
캡슐화(Encapsulation)
구현되는 부분을 외부에 드러나지 않도록 하여 정보를 은닉하고, 외부와 상호작용 할 때에는 메소드를 이용한다.
객체가 독립적으로 역할을 할 수 있도록 데이터와 기능을 하나로 묶어 관리한다.
상속성(Inheritance)
하나의 클래스가 가진 특징(함수, 멤버)을 다른 클래스가 물려받음으로써 기존 코드를 재활용한다.
다형성(Polymorphism)
여러개의 함수나 클래스가 동일한 이름이나 타입으로 사용될 수 있으며, 오버로딩과 오버라이딩을 통해 제공된다.
오버로딩은 같은 이름의 함수를 여러개 정의한 후, 파라미터에 따라 실제 호출할 함수를 구분하여 사용하는것이다.
오버라이딩은 부모클래스의 메소드와 같은 이름과 매개변수를 사용하되, 내부 로직을 재정의할 수 있는것이다.
추상화(Abstraction)
객체들의 공통된 특징을 도출하는것이다.
하나의 클래스로 만들어진 여러개의 인스턴스를 통해 클래스 또한 추상화의 개념을 가지고 있다는것을 볼 수 있다.
객체지향 설계의 5가지 원칙(SOLID 원칙)은 다음과 같다.
단일 책임 원칙(SRP; Single Responsibility Principle)
“어떤 클래스를 변경해야 하는 이유는 오직 하나뿐이어야 한다.”
커다란 추상 클래스를 두고 각 객체가 참조한 개체의 특성에 맞게 상속하여 클래스를 분리함으로써 단일책임을 둘 수 있다.
개방 폐쇄 원칙(OCP; Open Closed Principle)
“소프트웨어 엔티티(클래스, 모듈, 함수 등)는 확장에 대해서는 열려있어야 하며, 변경에 대해서는 닫혀있어야 한다.”
자바의 DB 미들웨어인 JDBC가 좋은 예이다. DB를 MySQL에서 오라클로 변경하더라도 Connection을 설정하는 부분만 변경해주면 된다. 즉, 자바 애플리케이션은 DB라 하는 주변의 변화에 닫혀있는것이다. DB를 교체한다는 것은 DB 자신의 확장에는 열려 있다는 것이다. 이 원칙은 객체지향 설계의 장점인 유연성, 재사용성, 유지보수성을 보장해준다.
리스코프 치환 원칙(LSP; Listov Substitution Principle)
“서브 타입은 언제나 자신의 기반 타입으로 교체할 수 있어야 한다.”
상속을 받은 하위 클래스의 인스턴스는 상위형 객체 참조 변수에 대입하였을 때, 상위 클래스의 인스턴스 역할을 하는데 문제가 없어야 한다.
인터페이스 분리 법칙(ISP; Interface Segregation Principle)
“클라이언트는 자신이 사용하지 않는 메소드에 의존 관계를 맺으면 안 된다.”
SRP와 ISP는 같은 문제에 대한 두가지 다른 해결책이라 볼 수 있다. 인터페이스 분리법칙은 여러 책임을 갖는 하나의 클래스를 분리하여 하위 클래스에 구현을 강제하는 인터페이스를 각 책임을 기준으로 여럿 만드는것이다.
의존 역전 원칙(DIP; Dependency Inversion Principle)
“고차원 모듈은 저차원 모듈에 의존하면 안 된다. 이 두 모듈 모두 다른 추상화된 것에 의존해야 한다.”
“추상화된 것은 구체적인 것에 의존하면 안 된다. 구체적인 것이 추상화된 것에 의존해야 한다.”
“자주 변경되는 구체(Concrete) 클래스에 의존하지 마라”
상위 클래스일수록, 인터페이스일수록, 추상 클래스일수록 변하지 않을 가능성이 높으며, 이러한 자신보다 변하지 않는것에 의존하여 변하기 쉬운것들의 영향을 받지 않게 해야 한다.
컴포넌트 기반 방법론
기존의 시스템이나 소프트웨어를 구성하는 컴포넌트를 조합하여 하나의 새로운 애플리케이션을 만드는 방법론
컴포넌트는 시스템에 종속적이지 않아 재사용 가능하며 교체가 가능한 특정 기능을 수행하는 모듈을 일컫는다.
객체지향적인 원칙을 지켜 구축한 기존 시스템의 해체, 재조립 과정을 통한 단기간의 소프트웨어 시스템 개발로써 고객의 요구변화에 신속하고 유연하게 대처하고자 하는것을 목표로 한다.
애자일 방법론
민첩한, 기민한이란 의미의로, 고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하면서 개발 과정을 진행하는 방법론이다.
제품계열 방법론
특정 제품에 적용하고 싶은 공통된 기능을 정의하여 개발하는 방법론이다.