21년 12월 23일_소프트웨어 공학 수강, 시스템 프로그래밍 수강, 329고깃집

목요일[329(고깃집)]

 

- 소프트웨어공학 7주 차 end

- 시스템 프로그래밍 7주 차 2교시 보다가 맘...

 

1. 소프트웨어공학 1교시 수강

 

º 아키텍처 개념

서브시스템 수준의 덩어리화 작업

º 아키텍처 역할

분석하여 설계하는 것,  pipe-fillter, mvc, layer 등의 스타일 혼용 적용, 설계 구현과 통합, 테이스팅까지 통합하는 뼈대임

요구사항 분석(아키텍처에 제약사항을 반영) -> 아키텍처 설계(컴포넌트(쉽게 만든 기술)와 인터페이스를 정의 및 시각 호화)-> 상세설계(아키텍처를 구성하는 컴포넌트의 내부 설계) -> 구현(컴포넌트 구현) -> 통합 및 시험(인터페이스 시험)으로 구성

º 아키텍처 표현

4+1 관점[유스 케이스 관점] (논리적 관점_분석/설계 , 구현 관점_프로그래머 서브시스템의 모듈 구조와 관계, 프로세스 관점_시스템 통합자, 시스템 성능, 확장성, 효율, 배치 관점_시스템 엔지니어 시스템 구성)

Usecase view 시스템이 사용자에게 제공하는 기능에 관심

logical view(dsign view) 클래스나 컴포넌트 종류와 이들의 관계에 초점

implementation view 소프트웨어 서브시스템의 모듈이 어떻게 구조화되어있는가에 관심

process view 실제 구동 환경을 살펴봄으로써 논리적 관점과 같이 시스템 내부의 구조에 최저 , 시스템이 동시성과 동기화에 관심

deployment view 시스템을 구성하는 처리 장치 간의 물리적인 배치에 초점, 시스템들의 물리적인 환경에서 어떻게 연고나 되어 실행되는지를 나타냄, 시스템의 분산 구조와 실행할 때 컴포넌트를 배치 상태를 나타냄

 

2. 소프트웨어 2교시 수강

 

º 아키텍스 스타일 개념과 특징

º 클라이언트 서버형

º 계층형

º 이벤트 기반 아키텍처

º MVC

º 파이프 필터

º 데이터 중심 아키텍처

º peer-to-peer 스타일

 

3. 소프트 웨어 3교시 

 

º 디자인 패턴의 개념과 특징

아키텍처 설계 수준보다 낮은 수준의 설계 문제에 재상용 가능한 설루션 제공

하위 설계(알고리즘과 자료구조) 장: 원활한 의사소통, 구조파 악용이, 설계 변경 요청에 대한 유연한 대처

단 : 객체지향 설계 구현 위주, 초기 투자 비용 부담

º 디자인 패턴의 해택

Gof 디자인 패턴 / 솔루션 : 디자인 패턴의 본질, 실행코드보다 추상적인 설계 조각 

º 디자인 패턴의 형식

관련 패턴 패턴은 서로 관련된 것이 있음, 유사한 패턴이 있는 경우 구분하기 위한 설명이 추가

º 싱글톤 패턴

단독 개체, 독신자라는 뜻 + 정확히 하나의 요소만 갖는 집합 / 특정 클래스의 객체가 한 개만 있도록 하며 하나로 제한

동일한 자원이나 데이터를 처리하는 객체가 불필요하게 

객체를 강제적으로 하나만 생성하려는 목적 - > 클래스 차체를 정적 변수로 생성자는 private로 유일한 객체를 접근하는 메서드

º 반복자 패턴

iterator 반복 객체 속 넣음 자료구조를 활용 집합 클래스의 자료구조와 상관없이 집합에 소속된 요소들을 쉽게 접근하기 위해 반복자에게 위임

º 어댑터 패턴

접속 소켓, (물건을 다른 것에) 맞추어 붙이다 : 서비스가 제공하는 인터페이스를 클라이언트가 기대하는 인터페이스로 변환  기존 클래스를 재사용할 수 있도록 중간에 맞춰주는 역할, 호환성이 없는 기존 클래스의 인터페이스를 변환해 재사용할 수 있도록 해줌

º 데코레이션 패턴

기존에 구현되어있는 클래스에 때때로 필요한 기능을 추가해나가는 설계 패턴 / 기능 확장이 필요할 때 대안으로 사용

합 관계와 위임을 사용하여 기존 클래스의 동작을 가볍고 유연하게 확장, 수정에 의한 추가, ocp원리에 위배

º 팩토리 메소드 패턴

상위 클래스에서 객체를 생성하는 인터페이스를 정의하고, 하위 클래스에서는 인터페이스를 생성하도록 하는 방식

객체를 생성하는 시점은 알지만 어떤 객체를 생성해야 할지 알 수 없을 때, 객체 생성을 하우 클래스에 위임하여 해결

º 추상 팩토리 패턴

구체적인 구현은 concrete Product클래스에서만 이루어짐 사용자에게 apl를 제공하고 인터페이스만 사용하여 부품을 조립하여 만듦, 추상적인 부품을 조합해서 추상적인 제품을 만듦

º 상태 패턴

동일한 객체 상태에 따라 다르게 처리해야 할 때 사용

º 옵서버 패턴 ovserver

클래스에 변화가 일어났을 때 감지하여 다른 클래스에 통보해주는 것

º saam 아키텍처가 시나리오를 실행할 수 있는지 여부를 결정

실행하지 못하는 경우, 시나리오를 지원하도록 아키텍처를 변경

º atam

여러 가지 품질 속성에 초점을 맞추어 평가하여 아키텍처의 trade - off 설계, 타협점을 찾아냄

 

4. 시스템 프로그래밍 1교시 

 

º 쓰레드의 생성

HANDLE Create Thread(

 

)

lpThredaAttribus 프로세스를 생성하는 함수, 핸들의 상속 여부 결정

dwStackSize 쓰레드 생성 시 해당 쓰레드를 위한 스택이 별도로 생성, 쓰레드 크기 지정

쓰레드는 독립적으로 생성이 프로세스만이 아니라 쓰레드에서도 별도로 생성

lpStartAddress 쓰레드를 동작하기 위한 함수

lpParameter 쓰레드 함수에 전달할 인자를 지정 ; 되돌려주는 값이 있는지 여부

dwCreatonFlags 쓰레드의 생성 및 실행을 조정하기 위해 사용

lpThreadld 쓰레드 ID를 전달받기 위한 변수의 주소 값 전달

 

쓰레드 소멸 ; return문을 통해 종료 및 소멸시키는 방법이 가장 이상적 (속도↑, cpu 사용도↑)

ExitThread는 특정 위치에서 쓰레드의 실행을 종료한 경우 (언제나 종료 가능, dwExitCode는 커널 오브젝트에 등록되는 쓰레드 종료 코드를 지정) ex VOID ExitThread { DWORD dwExitCode};

Teiminate Thread는 외부에서 쓰레드를 종료시키고자 하는 경우 (핸들을 사용, 순전히 외부에 의한 강제 종료, 쓰레드 스스로 종료 시점 결정)

 

º 힙 데이터 영역 그리고 코드 영역의 공유에 대한 검증

쓰레드는 메모리 공유 

º 동시 접근에 있어서의 문제점

전역 변수 total에 둘 이상의 쓰레드가 동시 접근하는 경우 쓰레드는 돌아가면서 실행

 

5. 시스템 프로그래밍 2교시

 

º 프로세스로부터의 쓰레드 분리

프로세스는 쓰레드가 담겨져있다.

º 쓰레드의 상태 변화

º Suspend 그리고 Resume

 

// 변명 아닌 변명을 하자면 오늘은 집에서 하다 보니.. 집중력이 많이 흐려졌다.

 

내일은 크리스마스 이브이다,

toworrow wish list

 

. 인프런 js수강 [어제 wish였는데 안 함ㅎ]

. 밀가루 하루만 끊어보기 (할 수 있을까..)