Software 공학 지식 모음

Programming Paradigm

Procedural Programming

Procedure를 통해서 추상화와 재사용성을 만들어내는 것이 핵심이며, 코드의 재활용성이 높고 프로그램의 흐름이 쉽게 이해되며, 모듈화와 구조화가 용이하다. 반면, Procedure를 호출하는 과정에서 필연적으로 비용이 발생한다. 복잡한 프로그램을 만들기 어렵다.

Procedural Programming의 전형적인 문제점

절차가 중심이 됨에 따라 현실세계의 문제를 모델링하여 해결하는데 보다 어렵고, 데이터 관리와 코드의 유지보수가 힘들다.

Object Oriented Programming

객체를 모델링하고 그 객체들의 집합으로 프로그램을 만드는 것을 OOP라고 한다. 관련된 데이터가 객체로 표현됨에 따라 Strong Cohesion을 갖고, 각 객체가 독립적으로 존재 함에 따라 Weak Coupling되는 것이 장점이지만, 상속구조에 따라 코드가 매우 복잡해 질 수 있고, 의도하지 않은 공유가 발생할 수 있으며, 유지보수에도 어려움을 겪을 수 있다.

Functional Programming

자료 처리를 수학적 함수의 계산으로 취급하고 상태와 가변 데이터를 멀리하는 것이 핵심이며, 객체지향 프로그래밍보다 강한 추상화를 통해서 상태 변경에 따른 부작용에서 자유로울 수 있다.

OOP Common

Encapsulation

객체의 필드와 메소드를 하나로 묶고, 실제 구현 내용을 외부에 감추는 것. 객체 단위로 Encapsulation 하여 프로그램을 구성하는 OOP의 핵심이된다.

Information Hiding

Encapsultion 을 통해서 객체의 정보 노출을 막는 것.

Inheritance

객체간의 관계중 하나로 Super Class의 필드와 메서드를 Sub Class가 상속 받아서 반복을 제거하고, 재사용성을 높인다.

Polymorphism

하나의 메소드나 클래스가 다양한 형태를 갖을 수 있는 것
Overloading - 하나의 메소드를 여러 모양으로 만들어서 사용
Overriding - Super Class에서 상속받은 것을 재정의하여 사용
Dynamic Binding - 클래스의 메소드가 Super / Sub Class 의 메소드 중 어떤 것이 호출될 것인지를 runtime시에 결정하는 것
Substitutability - 선언은 Super Class로 생성은 Sub Class로 하여 유연성을 높인다. 항상 Sub Class는 Super Class 역할을 할 수 있어야 한다.

Dynamic Binding이 OOP에서 필수인 이유

선언된 클래스에 실제 어떤 Instance가 생성될지 runtime시에 결정되기 때문에, Polymorphism 을 위해서 Dynamic Binding이 되어야 한다.

Abstract Class, Interface

추상 클래스는 클래스의 일부의 구현을 강제하는 클래스고 인터페이스는 규칙만 정해 놓은 빈껍데기다.

Generic Class (Java)

특정 데이터 형식과 관련이 없는 작업을 캡슐화 할 수 있도록, 타입 매개변수를 갖는 클래스

Template (C++)

Java 의 Generic Class와 매우 비슷하지만 조금 다른 특성을 가지고 있다. Java의 경우 컴파일러가 모두 downcasting 해주지만, C++은 별도로 생성하고, 따라서 static 변수를 공유하지 않는등의 차이가 있다.

SOLID

OOP에서 시간이 지나도 유지보수와 확장이 쉬운 시스템을 만들 수 있도록 가이드라인이 될만한 몇가지 원칙을 로버트 마틴이 정리하였고, 그 5가지 원칙의 앞글자를 따서 SOLID라고 명명했다. SRP, OCP, LSP, ISP, DIP

단일 책임 원칙 SRP(Single responsibility principle)

한 클래스는 하나의 책임만 가져야 한다.

개방-폐쇄 원칙 SCP(Open/closed principle)

소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.

리스코프 치환 원칙 LSP(Liskov substitution principle)

객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.

인터페이스 분리 원칙 ISP(Interface segregation principle)

특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.

의존관계 역전 원칙 DIP(Dependency inversion principle)

추상화에 의존해야지, 구체화에 의존하면 안된다.

Abstraction

어원에서 알 수 있듯이, 핵심적인 기능이나 개념을 뽑아낸 것. 피카소의 추상화는 눈으로 보이는 모양과 다르지만 그것이 피카소가 뽑아낸 그 사물의 모양인것이다. 추상화가 잘되어 있다는 것은 잘 뽑아냈다는 것.

SoC(Seperation of Concerns)

프로그램에 영향을 주는 정보들을 구분하여 분리하고 그 분리에 따라서 영역을 구분하여 설계하는 방법. Concern 은 HW 가 될 수도 있고, Class 또는 MVC처럼 Layer가 될 수도 있다.

Cohesion

응집도라는 낯선 이름보다 차라리 코히즌이라고 읽고 쓰는것이 낫다. Seperate of Concerns이 얼마나 잘 되었는지를 뜻한다. 즉, 어떤 모듈이 포함한 정보들이 그 모듈과 잘 맞는 것인지에 대한 척도다.

Coupling

결합도 노노. 커플링! 다른 모듈과의 의존관계의 정도를 뜻한다.

SW Design Pattern

디자인 패턴은 잘 정리된 곳이 많아서 열거만하고 넘어간다. 어떤 상황에서 쓰는지, 장단점, Class Diagram으로 표현, 비슷한 패턴간의 차이점도 알아둘 것.

Creation Patterns - Abstract factory, Builder, Factory method, Prototype, Singleton
Structural Patterns - Adaptor, Bridge, Composite, Decorator, Facade, Flyweight, Proxy
Behavioral Patterns - Chain-of-responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template method, Visitor

https://refactoring.guru 추천.ㅎ

Unified Modeling Language

하나같이 말하더라, 단지 Unified 되었을 뿐, 만능도 아니고 대단한 약속 같은 것도 아니라는 점.

Use Case Diagram

Use Case - 사용자 입장에서 바라본 시스템의 특성을 설명한 것으로 시나리오의 집합 형태를 갖는다. Use Case Diagram - Actor 중심으로 시스템을 구상하고, 시스템의 범위와 기능을 정의한 모델. Granularity그래뉼-래러리가 중요한데, 적정수준으로 세분화 되어야 함을 뜻한다.

Class Diagram

Dependency: 객체의 참조를 가지고 있지는 않지만 매개변수로 받거나 생성, 사용, 리턴하는 관계
Association: 일반적으로 다른 객체의 참조를 필드로 가지고 있는 연관 관계
Aggregation: Association 관계의 일종으로 참조를 가지고 있으나 인스턴스의 생성, 소멸에 관여하지 않는다. 연목에 오리가 있다.
Composition: Association 관계의 일종으로 참조를 가지고 있으나 인스턴스의 생성, 소멸에 관여한다. 사람은 두개의 손을 가지고 있다.
Generalization: 상속 관계

Sequence Diagram

상호작용의 오브젝트 간 메시지 시퀀스를 설명하는 다이어그램. 라이프라인, 메세지, 인터랙션으로 이루어진다.

State Machine Diagram

객체의 변화하는 상태(state)를 표현하는 다이어그램. State, Transition, Event(Trigger), Guard(Condition), Activity(Effect)로 이루어진다.

Timing Diagram

시간의 흐름에 따른 객체의 상태 변화를 모델링 하기 위한 다이어그램

Activity Diagram

처리 로직이나 조건에 따른 Work Flow를 모델링한 다이어그램 Action은 실행 가능한 단위이며, Activity는 여러 개의 Action을 포함할 수 있다.

Component Diagram

컴포넌트들과 시스템이 어떻게 연결되어 있는지 모델링한 다이어그램 Provided Interface - 컴포넌트에서 제공하는 인터페이스 Required Interface - 컴포넌트에서 사용할 인터페이스 Platform S/W에서는 추후에 Platform에 연결될 컴포넌트들이 제공해야 할 인터페이스에 대해서 정의를 잘 해야 하기 때문에 Required Interface의 설계가 중요하다.

Deployment Diagram

Node 위에 SW 산출물의 물리적인 Deployment에 대해 모델링한 다이어그램 Node 는 Device Node, Execution Environment Node(EEN)로 구분되며, Artifact는 바이너리, 스크립트, DB Table 등 물리적인 정보다.

Architecture Style

Data Flow

Data Flow Architecture

Batch Sequential - 여러개의 서브시스템이 순차적으로 데이터를 처리하는 구조. 서브 시스템이 독립적으로 구성될 수 있다. 대기시간이 길고, 처리량이 떨어지며, 동시 처리가 어렵다. 은행이나 Billing System.

Pipes & Filters - 파이프로 들어오는 데이터 스트림을 독립적인 필터를 통해서 연속적으로 처리하는 구조. 동시에 많은 양의 데이터를 처리할 수 있고, 필터를 재사용하거나 필터의 조합을 유연하게 구성할 수 있다. 필터간의 상호작용이나 동적인 재구성이 어렵다. UNIX 파일 시스템이나 센서의 데이터 처리.

Process Control - 프로세스를 제어하는 변수들의 셋이 데이터의 흐름을 결정하는 구조. 지정된 참조값에서 프로세스의 지정된 속성을 유지하는데 사용. 자율주행이나 핵발전소, 빌딩의 온도 조절등

Data-Centered

Data-Centered Architecture

Repository - Repository에 저장되는 데이터를 중심으로 Client들이 데이터를 교환하는 구조. Repository는 수동적, Client 는 능동적으로 동작한다. Repository의 확장과 데이터의 백업, 복구가 쉽다. 데이터 저장소의 데이터 구조와 Client 간에 의존성이 크고, 따라서 데이터 구조의 변경에 따라 많은 영향을 받으며, 데이터 이동에 따른 네트워크 비용이 발생한다. 일반적인 DBMS에서 사용된다.

Blackboards - Repository와 비슷한데, 반대로 Data Store 는 능동적이고, Client 또는 Knowledge Sources(Listeners 또는 Subscribers)는 수동적으로 동작한다. 동적인 문제를 해결할때 효과적이며, KS를 재사용할 수 있다. 테스트 하기 어렵다. AI와 같은 복잡한 문제를 해결할 때 사용. 알파고가 세돌이랑 대결할 때 미쿡에 KS들에게 최적의 수를 모아 모아서 결정.

Hierarchical

Main-Subroutine - 서브 루틴을 구성하고, 서브 루틴을 호출하는 구조. 탑다운 방식으로 쉽게 분리할 수 있으며, 서브루틴을 재사용 할 수 있다. 타이트하게 커플링 될 수 있다.

Mater-Slave - Master가 다수의 Slave를 관리하고, 사용하는 구조. 높은 신뢰성, 확장성을 갖는다. 높은 비용이 따른다. 하둡

Layered - Layer를 구분하여 SoC를 달성한다. 바로 아래 Layer와만 연결되어야 한다. Layer의 재사용이 가능하며 의존성이 제거됨에 따라 확장성, 유지 보수성이 좋아진다. Layer의 구분에 따라 성능 저하의 비용이 발생한다. 일반적인 Platform. OS.

Virtual Machine - 독립된 가상환경을 제공하는 구조. 플랫폼 독립적이고 이식성, 확장성이 좋음. 성능 비용이 크다. JVM, EC2 같은 가상 머신

Microkernel - 코어시스템과 플러그인 모듈로 구성하는 구조. 높은 이식성과 적응성을 갖는다. 복잡하고 성능 비용이 크다. 이클립스

Interaction-Oriented

MVC - 비즈니스 로직과 사용자 인터페이스를 분리한 구조.

PAC - 계층 구조를 구조를 이룬 Agent 들이 서로 협력하여 상호 작용 시스템 구조 형성. 각 Agent 는 Presentation, Abstraction, Control Component를 가지고 있으며 Control component 는 communications 을 담당하며 각각의 Agent 의 abstraction, presentation 은 다른 Agent 의 abstraction, presentation 와는 직접적인 연결이 없다. 다른 Component에 영향을 주지 않아 추가/변경이 쉽고, 재사용성이 높다. 개발복잡도가 높다. 분산 시스템에 사용된다.

Distributed Architecture

Client-Server - 다수의 클라이언트가 서버에 연결되는 구조. 사용자 인터페이스와 비즈니스 로직의 분리. 서버의 재사용이 가능. 서버 안정성에 따라 전체적 시스템 불안이 야기될 수 있다. Multi-tiers - SoC에 따라서 여러개의 Tier 로 구성하는 구조. 비즈니스 로직, 인터페이스, 데이터 베이스 등의 분리. 확장, 재사용성이 뛰어나지만 테스트가 어렵고, 네트워크 사용에 따른 비용 발생한다. Proxy - proxy 서버를 두어서 원격의 인스턴스를 대신하거나 보안을 강화하고, 또는 가상의 서비스나 인스턴스 역할을 하도록 할때 사용하는 구조. Broker - broker 서버를 중간에 위치시켜서 이기종 시스템을 연결하는 구조. 변경가능성, 확장성, 재사용성이 높아진다. 오버헤드에 따른 비용, fault-tolerance 가 낮고 테스트가 어렵다. Dispatcher - 로드밸런싱을 통해 가용성 확보하기 위한 구조.

Component-Based

SOA - Service-Oriented Architecture로 시스템을 서비스 관점으로 컴포넌트를 분리/결합하여 구성하는 구조로 제조사, 제품, 기술등으로부터 독립적이다. 재사용성, 확장성, 상호운용성이 뛰어나다. 컴포넌트 간의 연결이 원할 하도록 인터페이스와 프로토콜의 정의가 선행되어야 한다. 결재나 로그인처럼 서비스로 분리하여 재사용.

Software Engineering

SW Quality in ISO9126

국제표준에 명시된 SW 품질을 측정하는 기준으로 Functionality(Accuracy...), Reliability(Fault Tolerance...), Usability(Learnability...), Efficiency(Time Behaviour...), Maintainability, Portability로 구분된다.

SW Quality

Process Quality - Software Process를 평가
Internal Quality - Code를 평가, White Box Test
External Quality - Product를 평가, Black Box Test
Quality in Use - Usability를 평가, 최종 사용자의 평가

SAAM Software Architecture Analysis Method

아키텍처의 modifiability와 functionality에 집중한 평가 방법으로 변경요구가 프로젝트에 미치는 영향이 집중적으로 평가된다.

ATAM Architecture Tradeoff Analysis Method

품질 속성 시나리오에 기반하여 Architecture의 Tradeoff를 분석하고 이에 대한 위험 요소를 찾아내는 평가방법, 평가 경험에 기반한다.

품질 속성 분류 - Architecture 개선 - 리스크 추출
아키텍처 설계에 대한 논리적 기준 및 근거 제시, 개발자들에게 아키텍처 설계 원칙을 공유, 아키텍처 기반의 위험 관리(Risk Management) 수행

CBAM Cost Benefit Analysis Method

ATAM과 비슷하지만 비용을 고려하여 평가한다.

 

출처 : blog.msalt.net/241