소프트웨어 설계

🍇프로토타이핑 모형(Prototyping Model)

• 실제 개발될 소프트웨어에 대한 견본품(Prototype)을 만들어 최종 결과물을 예측하는 모형이다.
• 의뢰자나 개발자 모두에게 공동의 참조 모델을 제공한다.
• 새로운 요구사항이 도출될 때마다 이를 반영한 프로토타입을 새롭게 만들면서 소프트웨어를 구현하는 방법으로, 새롭게 도출된 요구사항을 충분히 반영한다.
• 단기간 제작 목적으로 인하여 비효율적인 언어나 알고리즘을 사용할 수 있다.

프로토타입 모형(Prototype Model)

• 사용자의 요구사항을 정확히 파악하기 위해 실제 개발될 소프트웨어에 대한 견본(시제)품(Prototype)을 만들어 최종 결과물을 예측하는 모형이다.
• 시제품은 의뢰자나 개발자 모두에게 공동의 참조 모델이 된다.
  _ 시스템의 일부 혹은 시스템의 모형을 만든는 과정으로서 요구된 소프트웨어를 구현하는데, 이는 추후 구현 단계에서 사용될 골격 코드가 된다.
• 새로운 요구사항이 도출될 때마다 이를 반영한 프로토타입을 새롭게 만들면서 소프트웨어를 구현한다.
• 단기간 제작을 목적으로 하다 보니 비효율적인 언어나 알고리즘이 사용될 수 있다.

🍈XP(eXtreme Programming)

• 단순한 설계를 통해 소프트웨어를 빠르게 개발하는 것을 목적으로 한다.
• 변화에 대응하기 보다는 변화에 반응하는 것에 더 가치를 둔다.
• 스파이크 솔루션은 기술 문제가 발생한 경우 이를 해결하기 위해 사용한다.
• 짝 프로그램(Pair Programming)은 독립적으로 코딩할때보다 더 나은 환경을 조성한다.
• 짧고 반복적인 개발 주기, 단순한 설계, 고객의 적극적인 참여를 통해 소프트웨어를 빠르게 개발하는 것을 목적으로 한다.
• 5가지 핵심가치 : 의사소통(Communication), 단순성(Simplicity), 용기(Courage), 존중(Respect), 피드백(Feedback)
• 비교적 소규모 인원의 개발 프로젝트에 효과적이다.

🍉요구사항 도출(Requirement Eilcitation)

• 요구사항 도출은 소프트웨어가 해결해야 할 문제를 이해하는 첫 번째 단계이다.
• 요구사항 도출 단계에서 개발자와 고객 사이의 관계가 만들어지고 이해관계자(Stakeholder)가 식별된다.
• 이 단계에서는 다양한 이해관계자 간의 효율적인 의사소통이 중요하다.
• 시스템, 사용자 그리고 시스템 개발에 관련된 사람들이 서로 의견을 교환하여 요구사항이 어디에 있는지, 어떻게 수집할 것인지를 식별하고 이해하는 과정이다.
• 요구사항 도출은 소프트웨어 개발 생명주기(SDLC software development life cycle)동안 지속적으로 반복된다.
• 요구사항을 도출하는 주요 기법에는 청취와 인터뷰, 설문, 브레인스토밍, 워크샵, 프로토타이핑, 유스케이스 등이 있다.

🍊CASE(Computer Aided Software Engineering)

• 자동화된 기법을 통해 소프트웨어 품질이 향상된다.
• 소프트웨어의 유지보수를 간편하게 수행할 수 있다.
• 소프트웨어의 생산성이 향상된다.
• 소프트웨어 모듈의 재사용성이 향상된다.
• 요구사항 분석을 위한 자동화도구
• 객체지향 시스템, 구조적 시스템 등 다양한 시스템에서 활용되는 자동화 도구(CASE Tool)이다.
• CASE 도구가 모듈 관리를 자동으로 수행하므로 유지보수가 간편해진다.
• CASE의 주요기능
  -소프트웨어 생명 주기 전 단계의 연결
  -다양한 소프트웨어 개발 모형 지원
  -그래픽 지원
  -모델들의 모순 검사 및 오류검증
  -자료흐름도 작성
• CASE의 원천 기술
  -구조적 기법
  -프로토타이핑
  -자동 프로그래밍
  -정보 저장소
  -분산처리

🍋관계

• Dependency(의존) : 하나의 사물의 변화가 다른 사물에도 영향을 미치는 관계로, 일반적으로 한 클래스가 다른 클래스를 오페레이션의 매개 변수로 사용하는 경우 나타나는 관계
• Generalization(일반화) : 하나의 사물이 다른 사물에 비해 더 일반적인지 구체적인지를 표현하는 관계
• Association(연관) : 2개 이상의 사물이 서로 관련되어 있음을 표현하는 관계
• Realization(실체화) : 사물이 할 수 있거나 해야 하는 기능(오퍼레이션, 인터페이스)으로 서로를 그룹화 할 수 있는 관계를 표현함

🍌UML 다이어그램의 종류

구조적(Structural) 다이어그램 = 정적 다이어그램

• 클래스 다이어그램(Class Diagram) : 클래스와 클래스가 가지는 속성, 클래스 사이의 관계를 표현
• 객체 다이어그램(Object Diagram) : 클래스에 속한 사물(객체)들, 즉 인스턴스(Instance)를 특정 시점의 객체와 객체 사이의 관계로 표현
• 컴포넌트 다이어그램(Component Diagram) : 실제 구현 모듈인 컴포넌트 간의 관계나 컴포넌트 간의 인터페이스를 표현
• 배치 다이어그램(Deployment Diagram) : 결과물, 프로세스, 컴포넌트 등 물리적 요소들의 위치를 표현
• 복합체 구조 다이어그램(Composite Structure Diagram) : 클래스나 컴포넌트가 복합 구조를 갖는 경우 그 내부 구조를 표현
• 패키지 다이어그램(Package Diagram) : 유스케이스나 클래스 등의 모델 요소들을 그룹화한 패키지들의 관계를 표현

행위(Behavioral)다이어그램 = 동적 다이어그램

• 유스케이스 다이어그램(Use Case Diagram) : 사용자의 요구를 분석하는 것으로 기능 모델링 작업에 사용함
• 순차 다이어그램(Sequence Diagram) : 상호 작용하는 시스템이나 객체들이 주고 받는 메시지를 표현
• 커뮤니케이션 다이어그램(Communication Diagram) : 순차 다이어그램과 같이 동작에 참여하는 객체들이 주고받는 메시지를 표현하는데, 메시지뿐만 아니라 객체들 간의 연관까지 표현
• 상태 다이어그램(State Diagram) : 하나의 객체가 자신의 속한 클래스의 상태 변화 혹은 다른 객체와의 상호 작용에 따라 상태가 어떻게 변화하는지를 표현
• 활동 다이어그램(Activity Diagram) : 시스템이 어떤 기능을 수행하는지 객체의 처리 로직이나 조건에 따른 처리의 흐름을 순서에 따라 표현

🍍유스케이스(Use Case)

• 유스케이스가 특정 조건에 부합되어 유스케이스의 기능이 확장될 때 원래의 유스케이스와 확장된 유스케이스와의 관계를 확장 관계라고 한다.
• 확장될 유스케이스에서 원래의 유스케이스 쪽으로 점선 화살표를 연결한 후 화살표 위에 extends라고 표기한다.

<<extends>>

🍎모바일 제스처(Mobile Gesture)

• Tap
• Double Tap
• Drag : 누른채 움직임, 오브젝트를 이동시킬 때나 텍스트를 복사할 때 주로 사용, 직선움직임이 아니여도 인식 가능
• Pan : 누른채 계속 움직임(panning), 화면에서 오브젝트를 이동할 때, 라인 그리기 혹은 확대된 이미지를 상하좌우로 움직여 탐색 할 때 사용하는 방식
• Press : 오래누르기
• Flick : 빠르게 스크롤
• Pinch : 두 손가락으로 넓히기/좁히기

🍏유스케이스(Use Case)

• 사용자 측면에서의 요구사항으로, 사용자가 원하는 목표를 달성하기 위해 수행할 내용을 기술한다.
• 사용자의 요구사항을 빠르게 파악함으로써 프로젝트의 초기에 시스템의 기능적인 요구를 결정하고 그 결과를 문서화할 수 있다.
• 유스케이스는 자연어로 작성된 사용자의 요구사항을 구조적으로 표현한 것으로, 일반적으로 다이어그램 형식으로 묘사된다.
• 유스케이스 다이어그램이 완성되면, 각각의 유스케이스에 대해 유스케이스 명세서를 작성한다.

• 와이어 프레임(Wireframe)
  페이지의 개략적인 레이아웃이나 UI 구성 요소 등 뼈대를 설계하는 단계이다.

🍐아키텍처 설계 과정

설계 목표 설정 ➡ 시스템 타입 결정 ➡ 스타일 적용 및 커스터마이즈 ➡ 서브시스템의 기능, 인터페이스 동작 작성 ➡ 아키텍처 설계 검토

🍑 마스터-슬레이브(Master-Slave) 아키텍처

• 일반적으로 실시간 시스템에서 사용된다.
• 마스터 프로세스는 일반적으로 연산, 통신, 조정을 책임진다.
• 슬레이브 프로세스에서는 마스터 프로세스에서 수행하는 연산, 통신, 제어 등의 기능을 제외하고는 별도로 제한되는 기능은 없다.
• 마스터 프로세스는 슬레이브 프로세스들을 제어할 수 있다.

✨마스터-슬레이브 추가 설명
최근에는 마스터를 메인(Main)이나 프라이머리(Primary)로, 슬레이브를 세컨더리(Secondary)나 레플리카(Replica) 등으로 대체하려는 움직임이 있다

🍒주요 아키텍처 패턴(Patterns)의 종류

• 레이어 패턴 : 시스템을 계층(Layer)으로 구분하여 구성하는 고전적인 방법 중의 하나로 각각의 서브시스템들이 계층 구조를 이루며, 하위 계층은 상위계층에 대한 서비스 제공자가 되고, 상위 계층은 하위 계층의 클라이언트가 됨
• 클라이언트-서버 패턴 : 하나의 서버 컴포넌트와 다수의 클라이언트 컴포넌트로 구성되는 패턴으로, 클라이언트가 서버에 요청하고 응답을 받아 사용자에게 제공하는 방식
• 파이프-필터 패턴 : 데이터 스트림 절차의 각 단계를 필터 컴포넌트로 캡슐화하여 파이프를 통해 데이터를 전송하는 패턴
• 모델-뷰-컨트롤러 패턴 : 서브시스템을 모델, 뷰, 컨트롤러의 세 부분으로 구조화하는 패턴텍스트

🍓객체지향 Class

• Class : 하나 이상의 유사한 객체들을 묶어서 하나의 공통된 특성을 표현한 것
• Transaction(트랜잭션) : 데이터베이스의 상태를 변환시키는 하나의 논리적 기능을 수행하기 위한 작업의 단위
• Sequence(시퀀스) : 특정 시간동안 수행되는 사건이나 행동 등의 순서
• Subroutine(서브루틴) : 메인 루틴에 의해 필요할 때 마다 호출되는 루틴

🥝객체지향 용어

• Encapsulation(캡슐화) : 데이터와 데이터를 처리하는 함수를 하나로 묶은 것
• Operation : 클래스가 수행할 수 있는 동작으로, 함수(메소드)라고도 함
• Inheritance : 이미 정의된 상위 클래스(부모 클래스)의 모든 속성과 연산을 하위 클래스(자식 클래스)가 물려받는 것

🍅객체지향 설계 원칙

• 인터페이스 분리 원칙
  -클라이언트는 자신이 사용하지 않는 메소드와 의존관계를 맺으면 안된다.
  -클라이언트가 사용하지 않는 인터페이스 때문에 영향을 받아서는 안된다.
• 단일 책임 원칙 : 객체는 단 하나의 책임만 가져야 한다는 원칙
• 개방-폐쇄 원칙 : 기존의 코드를 변경하지 않고 기능을 추가할 수 있도록 설계해야 한다는 원칙
• 리스코프 교체(치환)의 원칙 : 자식 클래스는 최소한 자신의 부모 클래스에서 가능한 행위는 수행할 수 있어야 한다는 설계 원칙

🥑응집도(Conhesion)

• 정보 은닉 개념을 확장한 것으로, 명령어나 호출문 등 모듈의 내부 요소들의 서로 관련되어 있는 정도, 즉 모듈이 독립적인 기능으로 정의되어 있는 정도를 의미한다.
• 다양한 기준으로 모듈을 구성할 수 있으나 응집도가 강할수록 품질이 높고, 약할수록 품질이 낮다.

🍆GoF(Gangs of four) 디자인 패턴

• 생성패턴(Creational Pattern), 구조패턴((Structural Pattern), 행위패턴(Behavioral Pateern)

🥔Singleton 패턴(생성패턴)

• 싱글톤패턴-생성패턴 : 하나의 객체를 생성하면 생성된 객체를 어디서든 참조 할 수 있지만, 여러 프로세스가 동시에 참조할 수는 없는 패턴이다.
• 프로토타입-생성패턴 : 원본 객체를 복제하는 방법으로 객체를 생성하는 패턴이다.
• 컴포지트-구조패턴 : 여러 객체를 가진 복합 객체와 단일 객체를 구분 없이 다루고자 할 때 사용하는 패턴이다.
• 중재자-행위패턴 : 수많은 객체들 간의 복잡한 상호작용을 캡슐화하여 객체로 정의하는 패턴이다.

🥕디자인 패턴

• 템플릿 메소드(Template Method)-행위패턴 : 알고리즘은 상위 클래스에서 정의하고 나머지는 하위 클래스에서 구체화하느느 패턴
• 옵서버(Oberver)-행위패턴 : 한 객체의 상태가 변화하면 객체에 상속되어 있는 다른 객체들에게 변화된 상태를 전달하는 패턴
• 상태(State)-행위패턴 : 객체의 상태에 따라 동일한 동작을 다르게 처리해야 할 때 사용하는 패턴
• 컴포지트(Composite)-구조패턴 : 여러 객체를 가진 복합 객체와 단일 객체를 구분 없이 다루고자 할 때 사용하는 패턴

🌽미들웨어

• TP-Monitor(Transaction Processing Monitor) : 트랜잭션이 올바르게 처리되고 있는지 데이터를 감시하고 제어
• RPC(Remote Processing Monitor) : 응용 프로그램의 프로시저를 사용하여 원격 프로시저를 마치 로컬 프로시저처럼 호출하는 방식의 미들웨어
• ORB(Object Request Broker) : 객체 지향 미들웨어로 코바(CORBA) 표준 스펙을 구현한 미들웨어

🍇정보공학 방법론

• 정보공학 방법론에서는 업무 영역 분석과 업무 시스템 설계 과정에서 데이터베이스 설계를 위한 데이터 모델링으로 Entity-Relationship Diagram(개체 관계도)을 사용

🍈객체지향 개발 방법론

• Package Diagram
• State Transition Diagram
• Deployment Diagram