원글 페이지 : 바로가기
* 2022 1, 2회차 / 2021 1, 2, 3회차를 정리한 내용입니다. UML(Unified Modeling Language) 다이어그램 (X): 절차 다이어그램(Procedural diagram) 액티비티(Activity) 다이어그램 클래스(Class) 다이어그램 시퀀스(Sequence) 다이어그램 – UML 객체 지향 시스템을 개발할 때 산출물을 명세화, 시각화, 문서화하는데 사용된다. 즉, 개발하는 시스템을 이해하기 쉬운 형태로 표현하여 분석가, 의뢰인, 설계자가 효율적인 의사소통을 할 수 있게 해준다. 따라서, 개발 방법론(X)이나 개발 프로세스(X)가 아니라 표준화된 모델링 언어이다. 기능적 모델은 사용자 측면에서 본 시스템 기능이며, UML에서는 Usecase Diagram을 사용한다. – UML 모델 1. Dependency(의존): 한 사물의 명세가 바뀌면 다른 사물에 영향을 주며, 일반적으로 한 클래스가 다른 클래스를 오퍼레이션의 매개변수로 사용하는 경우에 나타나는 관계. 어떤 클래스가 다른 클래스를 참조하는 것 참조하는 객체나 클래스가 사용 후 사라짐 ( 지역변수에 객체가 보관되어 메서드 종료시 사라진다 ) 2. Realization(실체화): 한 객체가 다른 객체에게 오퍼레이션을 수행하도록 지정하는 의미적 관계 인터페이스의 명세/정의만 있는 메서드를 오버라이딩해서 실제 기능을 구현하는 것이다. 3. Generalization(일반화): 슈퍼(부모)클래스와 서브(자식)클래스간의 상속관계 4. Association(연관): 객체를 인지하는 것 참조하는 객체나 클래스가 사용 후에도 계속 유지됨 (전역변수에 객체가 보관되어 클래스 생명 주기까지 유지된다.) 출처: https://velog.io/@ssuh0o0/%ED%97%B7%EA%B0%88%EB%A0%A4%EC%84%9C-%EC%A0%81%EC%96%B4%EB%86%93%EB%8A%94-UML-%EB%8B%A4%EC%9D%B4%EC%96%B4%EA%B7%B8%EB%9E%A8 – 순차(Sequence) 다이어그램 (X): 하나의 객체(X)가 가진 상태와 그 상태의 변화에 대한 동작 순서를 나타낸다. (X): 주로 시스템의 정적 측면(X)을 모델링하기 위해 사용 =(X): 동적 다이어그램보다는 정적(X) 다이어그램에 가깝다. 객체 간의 동적 상호작용을 시간 개념을 중심으로 모델링 하는 것이다. = 시간의 흐름에 따라 객체들이 주고 받는 메세지의 전달 과정을 강조한다. 다이어그램의 수직 방향이 시간의 흐름이다. 교류 다이어그램(Interaction Diagram)의 한 종류로 볼 수 있다. 회귀 메세지(Self-Message), 제어블록(Statement block) 등으로 구성된다. 출처: https://vanslog.io/posts/cs/uml/sequence-diagram/ – 유스케이스 다이어그램(Use Case Diagram) (X): 시스템과 상호작용하는 외부시스템은 액터로 파악해서는 안된다(X). (X): 사용자 액터는 본 시스템과 데이터를 주고 받는 연동 시스템(X)을 의미한다. (X): 연동의 개념은 일방적으로(X) 데이터를 파일이나 정해진 형식으로 넘겨주는 것이다. (X): 유스케이스 다이어그램은 개발자(X)의 요구를 추출하고 분석하기 위해 사용한다. 유스케이스는 사용자 측면에서의 요구사항으로, 사용자가 원하는 목표를 달성하기 위해 수행할 내용을 기술한다. 시스템 액터는 다른 프로젝트에서 이미 개발되어 사용되고 있으며, 본 시스템과 데이터를 주고받는 등 서로 연동되는 시스템을 말한다. 액터가 인식할 수 없는 시스템 내부의 기능을 하나의 유스케이스로 파악해서는 안된다. 액터는 대상 시스템과 상호 작용하는 사람이나 다른 시스템에 의한 역할이다. – 유스케이스(Use Case)의 구성 요소 간의 관계 (X): 구체화 1. 연관(Association): 유스케이스와 액터간의 상호작용이 있음을 표현 출처: https://googry.tistory.com/2 2. 포함(Include): 하나의 유스케이스가 다른 유스케이스의 실행을 전제로 할 때 형성되는 관계 ⬇️ 글을 등록하기 위해서는 로그인 기능이 실행되어야 한다. 출처: https://googry.tistory.com/2 3. 확장(Extend): 확장 대상 유스케이스를 수행 할 때 특정 조건에 따라 확장 기능 유스케이스를 수행하는 경우 기본 유스케이스 수행 시 특별한 조건을 만족할 때 수행하는 유스케이스. ⬇️ 글을 등록하는 기능을 수행할 때 파일을 첨부하는 기능을 선택적으로 수행할 수 있다. 출처: https://googry.tistory.com/2 4. 일반화(Generalization): 유사한 유스케이스 또는 액터를 모아 추상화한 유스케이스 또는 액터와 연결시켜 그룹을 만들어 이해도를 높이기 위한 관계. 구체적인 유스케이스에서 추상적인 유스케이스 방향으로 끝부분이 삼각형으로 표현된 화살표를 실선으로 연결하여 표현한다. ⬇️ 글을 검색한다를 글쓴이로 / 날짜로 검색한다로 좀 더 구체화하였다. 출처: https://googry.tistory.com/2 – 정적 다이어그램: 컴포넌트 / 배치 / 패키지 / 클래스 다이어그램 정적 모델은 객체, 속성, 연관관계, 오퍼레이션의 시스템의 구조를 나타내며, UML에서는 클래스 다이어그램을 사용한다. – 동적 다이어그램: 동적 모델은 시스템의 내부 동작을 말하며, UML에서는 Sqeunce, State, Activity 다이어그램을 사용한다. – 클래스 다이어그램의 요소 1. Operation 클래스의 동작을 의미. 클래스에 속하는 객체에 대해 적용될 메서드를 정의한 것. UML에서는 동작에 대한 인터페이스를 지칭한다고 볼 수 있다. 소프트웨어 모델링 구조적 방법론에서는 DFD(자료흐름도, Data Flow Diagram), DD(Data Dictionary) 등을 사용하여 요구사항의 결과를 표현한다. 객체지향 방법론에서는 UML 표기법을 사용한다. – 모델링(Modeling) (X): 유지보수 단계에서만(X) 모델링 기법을 활용한다. 절차적인 프로그램을 위한 자료흐름도(DFD)는 프로세스 위주의 모델링 방법이다. – 자료흐름도(DFD)의 구성 요소 (X): Data Store: 삼각형(X) 출처: https://velog.io/@tjrdbfl123/%EC%A0%95%EB%B3%B4%EC%B2%98%EB%A6%AC%EA%B8%B0%EC%82%AC-DFDData-Flow-Diagram-%EC%9E%90%EB%A3%8C%ED%9D%90%EB%A6%84%EB%8F%84-E-R-Diagram 출처: https://velog.io/@tjrdbfl123/%EC%A0%95%EB%B3%B4%EC%B2%98%EB%A6%AC%EA%B8%B0%EC%82%AC-DFDData-Flow-Diagram-%EC%9E%90%EB%A3%8C%ED%9D%90%EB%A6%84%EB%8F%84-E-R-Diagram 애자일 개발 방법론 (X): 하둡(Hadoop) 스크럼(Scrum) 익스트림 프로그래밍(XP, eXtreme Programming) 기능 주도 개발(FDD, Feature Driven Development) – 익스트림 프로그래밍(XP) : 애자일 방법론 중 하나 (X): 대표적인 구조적 방법론(X) 중 하나이다. (X): 빠른 개발을 위해 테스트를 수행하지 않는다(X). 소규모 개발 조직이 불확실하고 변경이 많은 요구를 접하였을 때 적절한 방법이다. 익스트림 프로그래밍을 구동시키는 원리는 상식적인 원리와 경험을 최대한 끌어올리는 것이다. 구체적인 실천 방법을 정의하고 있으며, 개발 문서보다는 소스코드에 중점을 둔다. 고객과 직접 대면하여 요구사항을 이야기하기 위해 사용자 스토리(User Story)를 활용할 수 있다. 기존의 방법론에 비해 실용성(Pragmatism)을 강조한 것. 소프트웨어 아키텍처 모델 외부에서 인식할 수 있는 특성이 담긴 소프트웨어의 골격이 되는 기본 구조. 이해 관계자들의 품질 요구사항을 반영하여 품질 속성을 결정한다. – MVC(Model-View-Controller) (X): 모델은 뷰와 제어 사이에서 전달자 역할(X)을 하며, 뷰마다 모델 서브시스템이 각각 하나씩 연결(X)된다. MVC 모델은 사용자 인터페이스를 담당하는 계층의 응집도를 높일 수 있고, 여러 개의 다른 UI를 만들어 그 사이에 결합도를 낮출 수 있다. 뷰는 모델에 있는 데이터를 사용자 인터페이스에 보이는 역할을 담당한다. 제어는 모델에 명령을 보냄으로써 모델의 상태를 변경할 수 있다. – 파이프 필터 아키텍처 (X): 데이터는 파이프를 통해 양방향으로 흐르며, 필터 이동 시 오버헤드가 발생하지 않는다(X). 서브시스템이 입력 데이터를 받아 처리하고 결과를 다른 시스템에 보내는 작업이 반복되는 아키텍처 스타일. – 데이터 중심 아키텍처 공유 데이터 저장소를 통해 접근자 간의 통신이 이루어지므로, 각 접근자의 수정과 확장이 용이하다. 아키텍처 설계 – 아키텍처 설계 과정 1. 설계 목표 설정 2. 시스템 타입 결정 3. 스타일 적용 및 커스터마이즈 4. 서브시스템의 기능, 인터페이스 동작 작성 5. 아키텍처 설계 검토 – 소프트웨어 아키텍처 설계에서 시스템 품질 속성 (X): 독립성(Isolation) 1. 가용성(Availability) 2. 변경 용이성(Modifiability) 3. 사용성(Usability) 객체지향 개념, 설계 1. 다형성(Polymorphism): 상속받은 여러 개의 하위 객체들이 다른 형태의 특성을 갖는 객체로 이용될 수 있는 성질. 2. 캡슐화(Encapsulation): 속성과 관련된 연산(Operation)을 클래스 안에 묶어서 하나로 취급하는 것. 연관된 데이터와 함수를 함께 묶어 외부와 경계를 만들고 필요한 인터페이스만을 밖으로 드러내는 과정. 3. 상속(Inheritance): 상위 클래스의 메소드와 속성을 하위 클래스가 물려받는 것. 4. 클래스(Class): 하나 이상의 유사한 객체들을 묶어 공통된 특성을 표현한 데이터 추상화. 5. 정보 은닉(Information Hiding) (X): 모듈 내부의 자료 구조와 접근 동작들에만 수정을 국한(X)하기 때문에, 요구사항 등 변화에 따른 수정이 불가능(X)하다. 필요하지 않은 정보는 접근할 수 없도록 하여 한 모듈 또는 하부시스템이 다른 모듈의 구현에 영향을 받지 않게 설계되는 것. 설계에서 은닉되어야 할 기본 정보로는 IP주소와 같은 물리적 코드, 상세 데이터 구조 등이 있다. 객체지향 분석기법 (X): 기능 중심으로 시스템을 파악하며 순차적인 처리가 중요시되는 하향식 방식(Top-down)(X)으로 볼 수 있다. 동적 모델링 기법이 사용될 수 있다. 데이터와 행위를 하나로 묶어 객체를 정의내리고 추상화시키는 작업이라 할 수 있다. 코드 재사용에 의한 프로그램 생산성 향상 및 요구에 따른 시스템의 쉬운 변경이 가능하다. 소프트웨어를 개발하기 위한 비즈니스(업무)를 객체와 속성, 클래스와 멤버, 전체와 부분 등으로 나누어서 분석해내는 기법. – Rumbaugh(럼바우) Method 객체 / 동적 / 기능(자료흐름도 DFD 주로 이용) 모형의 3개 모형을 생성하는 방법이다. – 럼바우 분석기법에서 정보모델링이라고도 하는 모델링 Object. – Coad-Yourdon E-R 다이어그램을 사용하여, 객체의 행위를 데이터 모델링하는데 초점을 둔 방법. 시스템 – 시스템의 구성요소 (X): Maintenance Process Feedback Control – 현행 시스템 분석에서 고려하는 항목 (X): 인적 자원 분석 DBMS 분석 네트워크 분석 운영체제 분석 분산 시스템 – 미들웨어(Middleware) (X): 미들웨어의 서비스 이용을 위해 사용자가 정보 교환 방법 등의 내부 동작을 쉽게 확인(X)할 수 있어야 한다. (X): 애플리케이션과 사용자 사이에서만(X) 분산 서비스를 제공. 분산 컴퓨팅 환경에서 서로 다른 기종 간의 하드웨어나 프로토콜, 통신환경 등을 연결하여 응용프로그램과 운영환경 간에 원만한 통신이 이루어질 수 있게 서비스를 제공하는 소프트웨어. 여러 운영체제에서 응용 프로그램들 사이에 위치한 소프트웨어이다. 소프트웨어 컴포넌트를 연결하기 위한 준비된 인프라 구조를 제공한다. 여러 컴포넌트를 1대 1, 1대 다, 다대 다 등 여러 가지 형태로 연결이 가능하다. 분산 시스템에서 다양한 부분을 관리하고 통신하며 데이터를 교환하게 해주는 소프트웨어. 위치 투명성(Location Transparency)을 제공. 분산 시스템의 여러 컴포넌트가 요구하는 재사용 가능한 서비스의 구현을 제공. – 메세지 지향 미들웨어(Message-Oriented Middleware, MOM) (X): 느리고 안정적인 업무보다는 즉각적인 응답이 필요(X)한 온라인 업무에 적합하다. 독립적인 애플리케이션을 하나의 통합된 시스템으로 묶기 위한 역할을 한다. 송신측과 수신측의 연결 시 메시지 큐를 활용하는 방법이 있다. 상이한 애플리케이션 간 통신을 비동기 방식으로 지원한다. – RPC(Remote Procedure Call): 응용 프로그램의 프로시저를 사용하여, 원격 프로시저를 로컬 프로시저처럼 호출하는 방식의 미들웨어. – 마스터-슬레이브(Master-Slave) 아키텍처 (X): 슬레이브 프로세스는 데이터 수집 기능을 수행할 수 없다(X). 실시간 시스템에서 사용. 마스터 프로세스는 연산, 통신, 조정을 책임. 마스터는 슬레이브들을 제어할 수 있다. 클래스 설계 원칙(SOLID) 1. 단일 책임원칙(SRP, Single Responsibility): 어떤 클래스를 변경해야 하는 이유는 오직 하나뿐이어야 한다. 2. 개방-폐쇄의 원칙(OCP, Open-Closed): 클래스는 확장에 대해 열려 있어야 하며 변경에 대해 닫혀 있어야 한다. 3. 리스코프 교체의 원칙(LSP, Liskov Substitution): 서브 타입은 언제나 자신의 기반 타입으로 교체할 수 있어야 한다. 4. 인터페이스 분리 원칙(ISP, Interface Segregation): 클라이언트는 자신이 사용하지 않는 메소드에 의존 관계를 맺으면 안 된다. 즉, 너무 많은 기능을 하나의 인터페이스에 넣기보다는, 필요한 기능만을 제공하는 여러 개의 인터페이스로 분리해야 한다. 5. 의존 역전 원칙(DIP, Dependency Inversion): 추상화된 것은 구체적인 것에 의존하면 안 된다. 설계 기법 – 하향식(Top-down) 설계 : 전체적인 것에서 시작하여 세부적인 사항으로 진행되는 것 통합 검사 시 인터페이스가 이미 정의되어 있어 통합이 간단하다. 레벨이 낮은 데이터 구조의 세부 사항은 설계초기 단계에서 필요하다. 소프트웨어 설계시 제일 상위에 있는 main user function에서 시작하여, 기능을 하위 기능들로 분할해 가면서 설계하는 방식 -> 모듈 간의 인터페이스와 시스템의 동작이 정상적으로 잘되고 있는지를 빨리 파악하고자 할 때 사용하는 것이 좋다. -> 넓이 우선(Breadth First) 방식으로 테스트를 할 모듈을 선택할 수 있다. – 상향식(Bottom-Up) 설계 : 세부적인 사항에서 시작하여 전체적인 것으로 진행되는 것 (X): 인터페이스가 이미 성립되어 있지 않더라도 기능 추가가 쉽다. 최하위 수준에서 각각의 모듈들을 설계하고 이러한 모듈이 완성되면 이들을 결합하여 검사한다. 출처: https://fineproxy.org/ko/wiki/top-down-and-bottom-up-design/ – 추상화(Abstraction) 기법 (X): 강도 추상화 1. 자료 추상화: 데이터 구조를 대표할 수 있는 표현으로 대체 2. 제어 추상화: 분기를 생각하며 추상화 3. 과정 추상화: 자세한 단계는 고려하지 않고, 상위 수준에서 수행 흐름만 먼저 설계 출처: https://chayan-memorias.tistory.com/90 CASE(Computer-Aided Software Engineering) (X): 소프트웨어 사용자들에게 사용 방법을 신속히 숙지시키기 위해 사용된다(X). 소프트웨어 모듈의 재사용성 향상 자동화된 기법을 통해 소프트웨어 품질 향상 소프트웨어 유지보수를 간편하게 수행할 수 있다. – CASE의 원천 기술 (X): 일괄처리(X) 기술 구조적 기법 프로토타이핑 기술 정보 저장소 기술 – 상위 CASE 도구가 지원하는 주요 기능 (X): 전체 소스코드 생성(X) 기능 모델들 사이의 모순검사 기능 모델의 오류검증 기능 자료흐름도(DFD) 작성 기능 인터페이스(Interface) 소프트웨어에 의해 간접적으로 제어되는 장치와 소프트웨어를 실행하는 하드웨어 기존의 소프트웨어와 새로운 소프트웨어를 연결하는 소프트웨어 순서적 연산에 의해 소프트웨어를 실행하는 절차 유저 인터페이스(User Interface, UI) – Feedback: 시스템의 상태와 사용자의 지시에 대한 효과를 보여주어, 사용자가 명령에 대한 진행 상황과 표시된 내용을 해석할 수 있도록 도와주는 것 – NUI(Natural User Interface): 멀티 터치(Multi-touch), 동작 인식(Gesture Recognition) 등 사용자의 자연스러운 움직임을 인식하여 서로 주고받는 정보를 제공하는 사용자 인터페이스. -CLI(Command Line Interface): DOS 및 Unix 등의 운영체제에서 조작을 위해 사용하던 것으로, 정해진 명령 문자열을 입력하여 시스템을 조작하는 사용자 인터페이스. – UI 설계 도구 1. 목업(Mockup) 디자인, 사용방법설명, 평가 등을 위해 실제 화면과 유사하게 만든 정적인 형태의 모형. 시각적으로만 구성 요소를 배치하는 것으로 일반적으로 실제로 구현되지는 않음 요구사항 – 요구 사항 개발 프로세스 순서 1. 도출(Elicitation) 2. 분석(Analysis) 3. 명세(Sepcification) 4. 확인(Validation) – 요구 분석(Requirement Analysis) * 요구 분석: 소프트웨어 개발의 실제적인 첫 단계로, 사용자의 요구에 대해 이해하는 단계. * 요구 추출(Requirement Elicitation): 프로젝트 계획 단계에 정의한 문제의 범위 안에 있는 사용자의 요구를 찾는 단계. * 도메인 분석(Domain Analysis): 요구에 대한 정보를 수집하고 배경을 분석하여 이를 토대로 모델링. – 요구 사항 정의 및 분석, 설계의 결과물을 표현하기 위한 모델링 과정에서 사용되는 다이어그램 (X): AVL Diagram DFD(Data Flow Diagram) UML Diagram E-R Diagram – 요구 사항 관리 도구의 필요성 (X): 기존 시스템과 신규 시스템의 성능 비교(X) 요구사항 변경으로 인한 비용 편익 분석 요구사항 변경의 추적 요구사항 변경에 따른 영향 평가 – 요구사항 모델링에 활용되는 것 (X): 단계 다이어그램(Phase Diagram) 애자일(Agile) 방법 유스케이스 다이어그램 시컨스(Sequence, 순차) 다이어그램 객체(Object) (X): 객체는 공통 속성을 공유하는 클래스들의 집합(X)이다. 상태, 동작, 고유 식별자를 가진 모든 것이라 할 수 있다. 필요한 자료 구조와 이에 수행되는 함수들을 가진 하나의 독립된 존재이다. 객체의 상태는 속성값에 의해 정의된다. 실세계에 존재하거나 생각할 수 있는 것. – 객체에게 어떤 행위를 하도록 지시하는 명령 Message. 모델(Model) (X): 모델을 통해 향후 개발될 시스템의 유추는 불가능하다(X). 개발 대상을 추상화하고 기호나 그림 등으로 시각적으로 표현한다. 디자인 패턴 : 소프트웨어 설계에서 자주 발생하는 문제에 대한 일반적으로 반복적인 해결 방법 – GoF(Gang of Four) (X): Strategy 패턴은 대표적인 구조 패턴(X)으로 인스턴스를 복제하여 사용하는 구조를 말한다. 1. 생성(Creational) 패턴 – Builder(빌더), Abstract Factory(추상 팩토리), Factory Method(팩토리 메소드), Prototype(원형), Singleton(단일체) -> Factory Method(팩토리 메소드) 패턴은 상위 클래스에서 객체를 생성하는 인터페이스를 정의하고, 하위클래스에서 인스턴스를 생성하도록 하는 방식이다. -> Prototype 패턴은 프로토타입을 먼저 생성하고 인스턴스를 복제하여 사용하는 구조이다. 2. 구조 패턴 – Adapter(어댑터), Bridge(브릿지), Proxy(프록시), Decorator, Facade, Flyweight -> (X): 브릿지 패턴은 기존에 구현되어 있는 클래스에 기능 발생 시, 기존 클래스를 재사용(X)할 수 있도록 중간에서 맞춰주는 역할을 한다. 3. 행동(행위) 패턴: 클래스나 객체들이 상호작용하는 방법과 책임을 분산하는 방법을 정의. – etc + Strategy(전략) + Mediator(중재자) + State(상태) -> Mediator 패턴은 객체 간의 통제와 지시의 역할을 하는 중재자를 두어 객체지향의 목표를 달성하게 해준다. 데이터 통신 관련 – 소켓 기술: 통신을 위한 프로그램을 생성하여 포트를 할당하고, 클라이언트의 통신 요청 시 클라이언트와 연결하는 내.외부 송.수신 연계기술 기타 – Component: 명백한 역할을 가지고 독립적으로 존재할 수 있는 시스템의 부분으로, 넓은 의미에서는 재사용되는 모든 단위라고 볼 수 있으며, 인터페이스를 통해서만 접근할 수 있는 것. – FEP(Front-End Processot): 입력되는 데이터를 컴퓨터의 프로세서가 처리하기 전에 미리 처리하여, 프로세서가 처리하는 시간을 줄여주는 프로그램이나 하드웨어. – instance: 같은 클래스에 속한 각각의 객체를 의미하는 것. – fan in/out