Meng's Algorithm

[소프트웨어 공학] 3. UML Class Diagram

Object

• Class 는 붕어빵을 만드는 틀이고, Object는 실제 붕어빵들이다.
• maxMiller가 Person이란 Class Object의 이름이다. 
• :Person처럼 때론 익명의 Object를 바로 만들어 바로 사용할 수 있다.
• Objects are instances of classes

Class

• Arrtibutes : Java로 따지면 필드
• Operations : Java로 따지면 Method
• 같은 클래스 타입의 객체라면 Attributes는 다른 값을 가질 수 있지만 , 행위 (Operation)은 같다.

Class Variable and Class Operation

• Class variable (= class attribute, static attribute) : 클래스당 하나만 정의된다. 모든 클래스의 인스턴스로부터 공유된다.
• Class operation (= static operation) : static 형의 공유되는 메소드
•  # 는 Protected, +는 Public , -는 Private
• Class variable 또는 Class operation은 밑줄이 있다.

Abstract Operations and Classes

• body가 없는 operation이다.
• <-> Concrete Operations and Classes
• 추상 클래스는 인스텐스를 만들수 없다.
• Abstract operation이 하나라도 포함한다면 Abstract Class다. (역은 참이아님)
• Abstract operation이 없어도 Abstract Class일 수 있다. 

•  <<abstract>>으로 표기하거나 {abstract} property를 준다. 
• 이름이 기울어진 글씨체라면 abstract class이다. 

Interfaces

• UML interface는 abstract operation의 집합이다.
• Provided interfaces : 클래스 또는 컴포넌트로부터 실현된, 구현된 인터페이스를 말한다. (일반적 생각하는 인터페이스)
• Required interfaces : 클래스 또는 컴포넌트로부터 공급을 받아야 하는 인터페이스 이다. ( 클래스안에 인터페이스 에 관한게 쓰인 경우)
• 노란색이 Provided , 파란색이 Required 인터페이스 임.

Types of class relationship

Dependency

Association

[소프트웨어 공학] 2. UML Overview

Software Modeling

• Model = Abstraction of the system 
  핵심적인 것만 담은 시스템의 추상화라 할 수 있다. 
  복잡도를 낮추기 위해 모델링을 사용한다.
• 고객, 개발자, 분석가 등등의 시스템 디자인, 분석등의 매개체 역할을 한다.
• Unified Modeling Language ( UML ) : 모델링의 표준

Categories of UML diagrams

• Structure Diagrams (구조적 다이어그램) : what things must be in the system
  • Class diagram
  • Component diagram
  • Deployment diagram
  • Composite diagram
  • Object diagram
  • Package diagram
• Behavior Diagrams (행위적 다이어그램) : what must happen in the system
  • Activity diagram
  • State diagram
  • Use case diagram
• Interaction Diagram (상호작용 다이어그램) : the flow of control and data among the things
      사실은 행위적 다이어그램에 포함된다.
  
  • Communication diagram
  • Interaction overview diagram
  • Seqeunce diagram
  • Timing diagram

Use-Case Diagram

행위자들과  Use case들 간의 독립성을 나타내는 함수를 보여준다.

Activity Diagram

한 스탭 스탭 마다의 workflows 제어 전부를 보여주는 flow chart이다. 

State Diagram

Activity 다이어그램과 비슷해보이지만 목적이 다르다. 우선 State Diagram은 대상을 1명으로 한다.

그리고 어떠한 State로 변하는지 다이나믹한 행동을 묘사한다. 

Sequence Diagram

액터들과 시스템 시스템의 객체들간의 다이나믹한 행동을 묘사한다. 

UML and Development Process

소프트웨어 개발 프로세스에서의 UML을 각각 단계마다 연결 시켜보았다.

[소프트웨어 공학] 1. 소프트웨어 개발 프로세스

그림 용어 설명

• 하나의 개발 프로젝트는 많은 액티비티로 구성되어 있다.
• 하나의 액티비티는 많은 tasks로 구성되어 있다. 
• 하나의 Task는 많은 WorkProduct를 생산하고 리소스들을 사용한다.
• Work Product : System, Model, Document
• Resource : Participant, Time, Equiment

소프트웨어 개발 프로세스

• SDLC 소프트웨어 개발 생명주기라고도 부른다. 
• 여러 액티비티와 그것의 관계를 나타낸 것
• 소프트웨어 개발에 질서를 부여한다.

Fundamental Activities in 소프트웨어 개발 프로세스

요구사항 추출 -> 분석 -> 시스템 설계 -> 디테일 디자인 -> 구현 -> 테스트

소프트웨어 개발 프로세스 모델

• SDLC model 이라고도 부른다.
• 소프트웨어 개발 프로세스의 추상적 표현이다
• 대표적 소프트웨어 개발 프로세스 모델
  
  • 순차적 모델
    • Waterfall model
    • V-model
  • 반복적 모델
    • 나선형 모델
    • Unified Process (RUP)

• Plan - driven Process : 미리 계획하고 잘되는지 관찰한다. 
• Agile Process 애자일 프로세스 : 일부 계획하고 또 일부 계획 하는 점증적 계획을 한다. 고객 요구사항 변화에 적응이 쉽다.
• 현실에선 둘 다의 특성을 가지고 있는 경우가 많다.

소프트웨어 프로세스 모델에서 어떤 건 옳고, 어떤 건 나쁜건 없다.

Sequential Development

Waterfall Model

전 단계가 검증되고 리뷰되어야만 다음단계가 시작된다. 

전단계로 되돌아 갈 수 없다. ( 있어도 타격이 크다)

Plan - driven 적 접근

• Advantages :

  심플하고 단계 구분이 잘 나뉘어있다. 

  요구사항이 쉬운 경우, 대규모 시스템인 경우 적합하다. ex) 비행기 

  관리자 측면에서 유용하다.

• Disadvantages :

  요구사항이 일찍 명세화되고 고정되어 있음을 가정한다. 

  하드웨어의 변화가 필요하거나 급진적 기술 변화가 있다면 좋지 않다.

  big bang의 방식 즉, 모든 것을 한번에 만들어내므로 위험에 취약하다.

  요구사항이 변경 불가능하므로 애초에 필요 이상으로 많아진다.

  상당한 량의 문서가 만들어 진다.

V - Model

Waterfall의 변형. Test단계를 좀 더 세분화 한 모델.

자동차 시스템과 같이 하드웨어와 소프트웨어가 합쳐진 경우

기능이 엄밀하게 사용되어야 되는 경우 쓰인다.

• Advantages :

  높은 품질과 테스트 효능이 강하다.

• Disadvantages :

  Waterfall과 같은 단점을 갖는다.

위 두 모델 모두 요구 사항을 변경하는데 취약하다

Development of prototype

프로토타입에 잘 이해하지 못하는 부분, 위험한 부분을 먼저 간추려 넣는다. 이것으로 더 구체적인 피드백을 앞서 받을 수 있다. 

• Advantages :

  요구사항이 쉽게 견고해진다.
  요구사항이 나중에 고정되도 된다.
  프로토타입을 만든 경험이 실제 개발에서 도움이 된다. 
  
  

• Disadvantages :

  예상보다 비용과 일정이 더 들어갈 수 있다.

Iterative and Incremental Development

   한번이 아닌 여러번에 거쳐 만든다.

   ex) UP, Agile....

• Benefits :

  위험을 줄임
  수정에 유연
  피드백에 유용
  여러번 테스트를 거치기 때문에 높은 품질

• Drawbacks :

  구조와 디자인이 최적이 아닐 수 있음
  다시 일하는 경우가 증가하고, 총 비용이 증가할 수 있다.

• 적합성 :

  장기적인 프로젝트의 위험을 줄여야 할 때 

  모든 요구사항을 확정 할 수 없을 때 

  응답시간이 중요할 때

Spiral Model : 나선형 모델

단계가 딱 정해져 있지 않다.

반복적 해결로 위험 요소를 해소한다

1. 개체 생성 ( Objective setting)
   단계를 위한 특정한 객체를 식별한다
2. 위험 해소 (Risk reduction)
3. 개발 및 검증 
4. 계획 
   다음 사이클에 대한 계획을 말함

Rational Unified Process (RUP) & Unified Process (UP)

반복적이며 아키텍처 중심적이고 유스케이스 중심이다. 

1. Inception Phase (도입 단계)

   사업에 타당성, 실현가능성 확인 
   비용 기간 범위 산정

2. Elaboration Phase (구체화 단계)

   리스크를 줄이고 견고한 아키텍쳐를 만든다

3. Construction Phase (구축 단계)

   프로토 타입을 기반으로 인도 가능한 최초 실행 버전의 소프트웨어 개발

4. Transition Phase (전이 단계)

   사용자가 테스트 해본다

📌 Tip : 각각의 단계가 소프트웨어 개발 프로세스 단계로 착각하는데, SDLC는 계속 이루어 지고 있다 ! 다음 사진을 보면 이해가 간다.

Waterfall이 리스크가 높음을 볼 수 있으며, 폭포수 단계는 중간 까지 눈에 보이는 성과가 없다. 

[네트워크] 3 - 1. Transport 트랜스포트 계층

Multiplexing / Demultiplexing

• Multiplexing : Socket으로부터 받은 데이터에 헤더를 추가한다.
• Demultiplexing : 받은 세그먼트를 올바른 Socket에 전달한다. 

TCP Soket Connection - oriented

• UDP는 목적지 Port 번호만 같으면 같은 Socket으로 간다. 
• TCP는 목적지 IP, 목적지 Port번호, 소스 IP , 소스 Port번호 4가지가 모두 같아야 같은 Socket으로 가고,
  하나라도 다를경우 다른 Socket으로 간다. (1:1) 

TCP Segment와 UDP Segment의 차이

• 실제 Data의 크기는 Header보다 훨씬 크다
• 세그먼트 Header에는 목적지, 소스 포트번호가 적혀있다. 
• TCP는 UDP에 비해 하는일이 많으므로 헤더에 그밖의 다른 것들이 있다.

RDT : Reliable Data Transfer

• Transport Layer은 RDT Protocol로 신뢰성 있는 전송을 하는 Reliable Channel 이지만 Network Layer는 Unreliable Channel이다. 
• 비신뢰성 채널에서 메세지 Error와 Loss가 생길 경우 어떻게 해결을 하는가? (= Checksum, Timer 등등)
• 만약 Network Layer에서 신뢰적인 전송을 한다면, Tranport Layer에선 보내고 받는것 빼곤 할 일이 없다. 

Packet Errors 를 위해 필요한 메카니즘

• Error Detection : 체크섬 비트를 추가한다.
• Feedback : 수신자가 잘 받았으면 ACKs, 못받았으면 NAKs 라는 피드백을 보낸다. 
• Retransmission : 송신자는 수신자의 피드백을 가지고 NAK의 피드백이 오면 Packet을 재전송한다.

• Sender : 피드백을 기다린다.
  Packet에 Sequence #를 추가한다.  
  수신자에게 NAK가 오면 재전송(udt_send(sndpkt)) 한다.  파란색글씨
• Receiver : Packet의 에러가 있으면 (corrupt)  NAK를 보내고, 에러가 없으면 (notcorrupt) ACK를 보낸다.
  패킷이 중복된 패킷인지 체크한다.

• 이렇게 패킷이 하나하나 보내진다고 가정하면(실제론 아님) ACK는 0,1으로만으로 피드백을 해결할 수 있다. 
• 중복으로 오는 Packet이 있다면 수신자입장애서는 처분한다.

Packet Loss를 위해 필요한 메카니즘

• Timer : 수신자로부터 피드백이 오는데 걸리는 최대 시간을 정해 놓는다. 정해진 시간안에 안오면 다시 보낸다.너무 길어도 짧아도 비효율적이다.

RDT 정리

• Unreliable한 Channel에선 패킷 error , loss가 일어난다. 
• Packet error를 위한 메카니즘 : Error detection, feedback, retransmission
• Packet loss를 위한 메카니즘 : Timeout! 

• 지금까지는 data packet이 하나가 전송되고 피드백이 완료되어야 다음 패킷이 출발한다고 간단하게 배웠지만,
  실제로는 Pipline 기법으로 data packet을 여러게 전송한다.