23년 1학기 14주 수업

ToC

• 모빌리티서비스
  • 초청 강연
    • 모빌리티
    • 진로 추천
• 알고리즘
• 소프트웨어분석및설계
• 소프트웨어디자인패턴

모빌리티서비스

• 기말고사 공지

초청 강연

모빌리티

• 모빌리티: 이동성
• 모빌리티 서비스: 이동성의 자유

벤츠
벤츠의 부인이 남편의 차를 타고 처음으로 시험주행했다. 이를 시작으로 지금의 브랜드 벤츠가 생겼다. 도전의 시작은 자기 자신을 믿는 것.

모빌리티서비스에는 뭐가 있을까?
우버, 그램, 쏘카, 그린카, 카카오T 등

차량 공유 기반의 모빌리티 서비스

1. 카 헤일링: 요청 시 태워줌. (예: 우버, 그랩, 카카오T 등)
2. 카 쉐어링: 차량을 빌려줌. 대여 및 반납 방식에 따라 구분. (예: 쏘카, 그린카, 피플카 등)
   1. 투웨이: 대여 위치로 돌아와 반납
   2. 원웨이: 지정된 주차장 아무데나 반납
   3. 프리플롯팅: 특정 지역 안에서 자유 픽업/반납

자동차의 전자화

1. 안전하고 튼튼한 자동차, 잘 달리고 잘 멈추는 차
2. 편리/즐거움을 주는 자동차, 환경친화적인 자동차

커넥티드 카: 자동차에 통신이 접목됨. 요즘 자동차는 스마트폰만 갖고 가면 문이 알아서 열린다.

자율주행이 뭐가 좋냐? 새로운 사업 기회가 열린다. 차에서 운전 안하고 딴짓할 수 있다. 차량에 스크린이 붙을 수 있다.
모빌리티는 사람의 자유를 확장한다.

왜 모빌리티를 파는가?

1. 인구 고령화, 감소 + 평균수명 연장: 조만간 한국 사회는 초 고령화 사회가 된다.
2. 사회적 양극화: 부익부 빈익빈. 교통 편의 양극화(버스가 하루에 한두번만 다니는 지역이 있다)
3. 기술의 발달: ACES(자율 주행, 통신 연결, 전기차, 공유차 플랫폼). 자동차 산업이 제조업에서 서비스업으로 변화했다.
4. 교통 이용 형태 변화: 젊은 세대에서 소유보다 공유 문화가 확산됨.

모빌리티의 가능성

• 끊임없이 연계될 수 있는 다양한 서비스: 사람이 타는 차량 예약, 물건 주문 및 배달 등

미래 모빌리티

• 차량의 소유는 개인 소유보다 공유로: 변화를 촉진하기 쉬워짐
• 사람 운전보다 자율 주행으로: “지정 주차 구역”이 필요 없어질 수 있다.
• 결국엔 공유 자율 주행 차량의 시대

차량 생산 기업의 경쟁력

• 현재 차량 생산 기업의 하드웨어 기술은 이미 포화 상태. 이제는 브랜드 이름만 보고 차를 살 이유가 줄어들고 있다.
• 그럼에도 계속 브랜드 가치를 유지하려면 그만한 서비스를 제공해야 한다. 그것이 모빌리티 서비스.

모빌리티의 사업 기회

• 패러다임의 변화
• 인간 삶의 모든 영역

전기차는 연료차보다 트렁크가 작은 경우가 많다

진로 추천

• “지금” 잘 되고 있는 곳은 안 된다. 나중에 물 빠지면 잘린다. 성장 가능성이 보이는 분야에 들어가서 하나씩 쌓아올려라.
• 무슨 직업을 갖든 기본적인 재무 지식은 반드시 도움이 된다. 꼭 공부하라.
• 항상 당당할 수 있게 열심히 좀 살아봐라

알고리즘

knapsack 복습

item이 3개 있다. 최대 S = 5이다.

1. X_1 = 10, S_1 = 4
2. X_2 = 25, S_2 = 2
3. X_3 = 7, S_3 = 3

그래프 관점에서 보자. 처음엔 S가 비어 있는 상태인 하나의 노드에서 시작한다. 이후 아이템을 하나씩 확인하는 것마다 하나의 레이어로 간주한다. 위 상황에서 output 레이어를 포함해 각 레이어가 가질 수 있는 노드는 S = 0일 때부터 S = 5일 때까지 총 6개이다.

각 노드는 현재 판단중인 아이템의 번호 X와 현재 채워진 용량 S를 갖는다.

1. (0, 0): 초기 상태
2. (1, 0): 첫 번째 아이템을 들고 넣을까 말까 고민하고 있음
3. (2, 0): 첫 번째 아이템을 넣지 않았고, 두 번째 아이템을 넣을까 말까
4. (2, 4): 첫 번째 아이템을 넣었고, 두 번째 아이템을 넣을까 말까
5. (3, 0): 아직 아무것도 넣지 않았고, 세 번째 아이템을 넣을까 말까
6. …

위의 과정에서 아이템을 넣거나 넣지 않음에 따라 변화하는 주머니 가치의 총량은 각 간선의 가중치가 된다.

소프트웨어분석및설계

• 지난 주 복습
  • UP는 기본적으로 반복 개발 모델이다. 점증적 개발. 하나의 분석으로부터 여러 개의 설계를 만들고 각자 릴리즈하거나, 여러 개의 분석으로부터 독립적으로 개발해 릴리즈하는 방법이 있음.
  • 폭포수 모델은 각 단계를 완전히 끝낸 후 다음 단계로 넘어간다. 구현 단계 이전까지는 프로그래머들이 할 일이 없다.
  • BPR: Busines Process Reengineering. ISP 과정 중에서 현재 구현 대상인 비즈니스의 흐름을 검토하고 재설계.
  • ISP: Information Strategy Planning. 큰 시스템 개발하기 전에 개발 비용 견적 산출.
• 메소드 오버로딩: 같은 이름 다른 파라미터
• 메소드 오버라이딩: 같은 이름 다른 클래스
• 설계의 원리
  • 추상화: 복잡한 소프트웨어의 설계를 단순화하고 관리하기 위한 목적으로 세부 정보를 숨긴다. 특정 구현 사례에서 문제와 관련된 범주 및 개념을 분리할 수 있다. 이는 특정 세부 사항(예: 지원 애플리케이션, 운영 체제 소프트웨어 또는 하드웨어)에 의존하지 않도록 코드를 작성할 수 있음을 의미한다.
  • 정보 은닉: 모듈의 선택된 알고리즘 및 데이터 구조와 관련된 내부 설계 결정을 외부로부터 숨기는 설계 원칙. 내부 설계 결정이 변경될 가능성이 가장 높다. 따라서 향후 설계의 유지보수 또는 수정으로 인한 부작용을 줄이고 설계의 다른 모듈에 미치는 영향을 최소화할 수 있다.
  • Separation of concerns: 컴퓨터 프로그램을 여러 섹션으로 분리하여 각 섹션이 별도의 관심사를 다루도록 하는 설계 원칙이다. 우려 사항은 컴퓨터 프로그램의 코드에 영향을 미치는 일련의 정보이다. SoC를 잘 구현하는 프로그램을 모듈형이라고 한다. 모듈화, 즉 관심사 분리는 잘 정의된 인터페이스를 가진 코드 섹션 내부에 정보를 캡슐화함으로써 달성된다.
  • 인터페이스: 인터페이스는 모듈 또는 시스템이 통신하는 액세스 지점이다. 각 추상화에는 추상화에서 예상되는 입력과 출력을 명확하게 설명하는 잘 정의된 인터페이스가 있어야 한다. 객체가 완전히 캡슐화된 경우 인터페이스는 다른 객체가 객체에 액세스할 수 있는 유일한 방법을 설명한다. 일부 프로그래밍 언어는 명시적으로 인터페이스를 지원한다(C#, Java, Objective-C, PHP 등).
  • Modularity: 대규모 소프트웨어 시스템을 상호 연결된 작은 모듈로 분할한다. 모듈은 인터페이스를 통해 상호 연결된다. 상호 연결은 부작용과 유지보수 비용을 피하기 위해 가능한 한 간단하고 적게 이루어져야 한다. (1) 직접 연결: 한 모듈이 다른 모듈을 호출할 수 있다. (2) 간접 연결: 공통 파일 또는 전역 데이터 구조를 공유한다.
  • 분할 정복: 모듈의 세부 설계 또는 알고리즘을 개발할 때 사용되는 개념이다. 문제를 재귀적으로 더 작은 하위 문제로 나누는 것을 기반으로 한다. 백트래킹은 도달한 가장 낮은 하위 문제가 해결되어 원래 문제의 해결에 기여할 때 발생한다.
• 디자인 패턴: 성공적인 설계의 재사용, 표준 형식 제공, 의사소통 원활하게 해줌, 설계 수정 용이, 설계 문서화 개선, 설계 이해도 상승
• 디자인 패턴의 구분
  • 생성 패턴: 객체 생성 과정. 추상 팩토리(abstract factory), 빌더(builder), 팩토리 메서드(factory method), 프로토타입(prototype), 싱글톤(singleton)
  • 구조 패턴: 객체와 클래스의 구성. 어댑터(adaptor), 브리지(bridge), 복합(composite), 데코레이터(decorator), 파사드(facade), 플라이웨이트(flyweight), 프락시(proxy)
  • 행동 패턴: 클래스와 객체가 맞물려 동작할 때의 책임. 책임체인(change of responsibility), 명령(command), 인터프리터(interpreter), 반복(iterator), 중재자(mediator), 메멘토(memento), 관찰자(observer), 상태(state), 전략(strategy), 템플릿 메서드(template), 방문자(visitor)

소프트웨어디자인패턴

• proxy 패턴
  • 대리인(“프락치”라고 부르던 그 단어가 맞음). 실제 서비스와 같은 이름의 메서드를 구현하고, 실제 서비스에 대한 참조 변수를 갖고, 실제 서비스의 같은 이름을 가진 메서드를 호출하고 값을 클라이언트에게 반환함. 실제 서비스 메서드 호출 전후로 별도 동작 가능. 실제 서비스는 ‘주체’라고 칭하는 것이 통상적이고, 의미가 잘 통한다.
  • 주체 클래스, 대리인 클래스, 공통 인터페이스, 클라이언트. 주체와 대리인은 공통 인터페이스를 상속 구현하고, 클라이언트는 대리인을 사용, 대리인은 주체를 갖고 사용함. 인터페이스는 주체와 대리인을 동일시하기 위함. 주체 클래스를 직접 다루는 부분에서는 synchronized를 사용해야 한다.
  • 중간부터 객체를 생성하는 시퀀스 다이어그램에 유의.
  • 다음 세 가지 프록시 타입은 시험에 나온다. 예시 코드를 바꿔서 낼 것이니, 코드의 어느 부분에서 시간이 걸리는지 확인하고 어떤 유형의 프록시인지 파악하기.
  • 가상 프록시: 꼭 필요한 시점까지 객체 생성 연기. 작은 단위 작업은 프록시가 처리하고, 리소스가 많이 필요한 작업이 요구될 때에만 주체 클래스를 사용하게 함. 속도 향상 타입. 초기화하는데 시간이 많이 걸리는 대규모의 시스템에서 유용하다.
  • 원격 프록시: 원격 객체에 대한 접근을 제어(로컬 환경에 존재하며, 원격 객체에 대한 대변자 역할을 함). 구글 클라우드 서비스와 비슷함. 구글 독스처럼 서로 다른 주소 공간에 있는 객체에 대해 마치 같은 주소 공간에 있는 것처럼 동작하게 함. 멀리 떨어져 있어도 지금 같이 있는 것처럼
  • 보호 프록시: 주체 클래스에 대한 접근을 제어. 객체에 대한 접근 권한을 제어하거나 객체마다 접근 권한을 다르게 할 수 있음. 프록시가 클라이언트의 주체 클래스에 대한 접근을 허용할지 말지 결정. 귀한 곳에 누추하신 분이 오면 입장권 확인
  • HTTP proxy 예시: Proxy는 HTTP 서버(웹 서버)와 HTTP 클라이언트(웹 브라우저) 사이에 들어가, 웹 페이지의 캐싱 등을 실행하는 소프트웨어. 웹 브라우저가 웹 페이지를 표시할 때, 일일이 원격지에 있는 웹서버로부터 페이지를 얻어오지 않고 HTTP 프록시가 캐쉬한 페이지를 얻어온다. 최신 정보가 필요하게 되었거나, 페이지의 유효기간이 다 되었을 때에 비로소 웹 서버로 웹 페이지를 가지러 간다.
  • 장점: 사이즈가 큰 객체가 로딩되기 전에도 프록시를 통해 참조 가능. 실제 객체의 public, protected 메소드를 숨기고 인터페이스를 통해 노출 가능. 로컬에 있지 않고 떨어져있는 객체를 사용 가능. 원래 객체에 접근에 대한 사전처리 가능.
  • 단점: 객체를 생성할 때 한 단계를 거치게 되므로, 빈번한 객체 생성이 필요한 경우 성능 저하 가능. 프록시 내부에서 객체 생성을 위해 스레드가 생성, 동기화가 구현되어야 하는 경우 성능 저하 가능. 로직이 난해해져 가독성이 떨어질 수 있음.
• facade 패턴
  • 하우스 인테리어를 한다고 치자. 도배, 목공, 싱크, 타일 등 할 일이 많다. 즉 다뤄야 할 저수준 객체가 많다. 많은 객체에 의존성을 갖게 되는 것이 문제다. -> 많은 저수준 객체들을 감싼 고수준 객체를 만들면 된다. 예를 들면 인테리어 회사.
  • 라이브러리/프레임워크/다른 클래스들의 복잡한 집합에 대한 단순화된 인터페이스를 제공하는 구조적 디자인 패턴. 예를 들면 어떤 회사에 어떤 문의를 하기 위해 전화를 걸었을 때 먼저 전화를 받아 적절한 부서로 연결해주는 상담원.
  • 파사드 클래스, 다수의 서브 클래스, 클라이언트. 클라이언트는 파사드 클래스를 사용하고, 파사드 클래스는 서브 클래스들을 모두 갖고 사용함. 파사드 클래스가 클라이언트용 인터페이스 역할을 함. 파사드는 서브 클래스를 호출하지만 서브 클래스는 파사드를 호출하지 않음.
  • 예제: 영화를 볼 때 복잡한 서브 클래스 없이 해결하기. 서브클래스에는 리모컨, 영화, 음료수 클래스가 있고, 파사드 클래스가 서브클래스들을 모두 혼자 컨트롤함. 사용자는 파사드 클래스를 이용해 ‘영화 보기’ 버튼만 누르면 됨.
  • 복잡한 하위 시스템에 대해 제한적이지만 간단한 인터페이스가 필요할 때 사용, 하위 시스템을 계층으로 구성하려고 할 때 사용(mediator pattern).
  • 장점: 복잡한 하위 시스템에서 코드를 별도로 분리할 수 있다.
  • 단점: 파사드는 앱의 모든 클래스에 결합된 전지전능한 객체가 될수 있다.
• 패턴별 장단점 모두 알아야 한다. “패턴을 적용했을 때의” 장점과 단점이다.