발표 주제정하기



1. Let's see. A is OK. How about changing the title, though? It's a bit stiff.

자 봅시다, A도 좋지만 제목을 바꾸는 것은 어때요? 좀 딱딱해요.


구어체로 비록 ~ 이지만. S+V, though = Although S + V 와 같다.


2. Our presentation isn't about A but also B.


우리의 발표는 A가 아니라 B다.


3. A's the first topic everybody reaches for. It's pretty typical.

Everybody knows it! Common topics! Predictable theme!


A는 모두가 손 대는 첫 주제이다. 꽤 전형적이다. 모든 사람들이 다 알고 있다. 흔한 주제야. 예측할만한 뻔한 테마(띰이라 발음)


4. You've got it. That's exactly the point i was trying to make.

맞아요.(이미 내가 생각한 것을 상대방이 생각할 때) 제가 생각한 포인트가 그거죠.


5. What am i supposed to do? I don't have time to think up new topic.

내가 어떻게 해야 하지? 나는 새로운 토픽을 생각해낼 시간이  없어.






'영어 > 영어회화' 카테고리의 다른 글

could / would  (0) 2018.01.12
점심거리 사러갈 때  (0) 2018.01.11
can / can't  (0) 2018.01.03
should / have to / must / be supposed to  (0) 2018.01.03
3인칭 단수 주어  (0) 2018.01.03

일반화와 상속의 차이



starUML을 사용하다보니 다음과 같은 의문이 들었다.


" 상속(Inheritance) 기호를 왜 일반화 기호로 표기했을까? "



Generalization이라 표기되어있는 상속기호



고민을 하다보니, 문득 예전에 객체지향프로그래밍 과목(C++) 시간에배운 is-a / has-a 관계가 생각났다.

따라서, 이번 글에서는 일반화와 상속의 차이에 대해 정리하고, is-a / has-a 관계에 대해 리뷰해보는 시간을 가져보자.



1. is-a


사람과 학생 클래스가 있다. 이들의 관계를 표현해보자



is-a 관계가 성립할 때 이를 상속으로 표현할 수 있다.

 

1) Person is a student. : 사람은 학생이다.  -> 논리적으로 옳지 않다. 모든 사람은 학생이 아니기 때문이다.

 2) Student is a person. : 학생은 사람이다.  -> 논리적으로 옳다. 모든 학생은 사람이라는 속성을 가진다.


따라서 is-a 관계에 의해 우리는 위의 다이어그램과 같이 person클래스를 상속받는 학생 클래스를 만들 수 있다. 



2 has-a


학생증이라는 클래스를 추가해보자. 이들의 관계를 표현해보자.




학생 has a 학생증.



is a 관계라 가정하면, 다음과 같이 표현할 수 있다.


1) Student is a student card. : 사람은 학생증이다. -> 논리적으로 옳지 않다

2) Student card is a student. : 학생증은 사람이다. -> 논리적으로 옳지 않다


매우 어색하다. 우리는 이를 표현하기 위해 has - a 관계라는 것을 정의함으로써 다음과 같이 올바르게 표현할 수 있다.  


 3) Student has a student card. : 


즉, 우리는 이와 같은 관계를 가질 때 이를 has-a 관계라고 부르며, 포함(Aggregation) 관계라 부르기도 한다. (일반적으로 필드가 객체를 포함하는 상황에서 has-a 관계를 가진다)


이때 한가지 더 첨언하자면, 학생 클래스 객체가 생성되면 학생 객체가 학생증 클래스의 생성자를 호출해 학생증 객체를 만든다. <-- 개념 다시 정리





이제 본격적으로, 일반화와 상속의 차이에 대해 이해해보자.


1. 일반화 (Generalization)


Bottom-up Process로 비슷한 클래스끼리의 공통 유사 속성을 묶은 것이다. 일반적으로 is-a 관계로 표현될 수 있으며,

Specialization Class is a Generalization Class. 로 나타내어진다.

( 구체화 클래스 is a 일반화 클래스 )






사진 출처 : http://www.universalteacherpublications.com/univ/free-asgn/2008/mcs32/page1.htm



위의 예시를 보면 shape 의 한 종류로 사각형, 원, 삼각형이 있는 것을 알 수 있다. 도형이라는 속성으로 일반화가 되었다고 볼 수있다. (반대로 구체화과정을 거치면 shape를 구체화하면 사각형, 원, 삼각형이 될 수 있다는 걸 알 수있다.)




2. 상속


(정의 보강 예정)

부모클래스로부터 자식클래스가 물려받을 때, 우리는 이를 상속이라고 부른다. 일반화관계일 때 보통 상속구조를 가질 수 있다.

예를 들어 학생이 사람을 상속받는다면, 사람의 속성을 학생이 다 가질 수 있기 때문이다.



따라서 관점의 차이에서 만들어낸 용어의 차이로,  일반화와 상속은 같은 뜻을 가진 용어라고 봐도 무방하다.







'IT 지식 > 공통' 카테고리의 다른 글

UML 클래스 다이어그램(1)  (0) 2018.01.07

UML 클래스 다이어그램




UML은 Unified Modeling Language의 약어로,클래스들의 구조도를 표현한 다이어그램이라 볼 수있다. 

객체간의 관계를 표현함에 있어 최적의 표현 방법이다. 시스템 시각화나 사양 및 설계를 문서화할 때 주로 사용되며 소프트웨어공학 시간에 UML 클래스 다이어그램을 배우게 된다.  UML을 쉽게 그릴 수 있도록 지원하는 소프트웨어들이 있는데, 나의 경우 무료인 Star UML이나 마이크로소프트에서 나온 유료 소프트웨어인 Visio를 쓴다.


이번 글에서는 자바 클래스/인터페이스를 기준으로 어떻게 UML 다이어그램을 그리는지 알아보자.



클래스 또는 인터페이스를 표현하는 방법은 다음과 같다.



1. 세칸으로 나눈 네모박스를 그린다.

 UML 프로그램에서는 이를 클래스 선택시 간편하게 그려주고 자동으로 조절해준다.


2. 클래스 이름을 적는다. 인터페이스의 경우 <<interface>>라고 타입을 표기해주는 것이 좋다.

 ex)   <<interface>> 

        인터페이스 이름

  또한, 추상클래나 인터페이스의 경우 이탤릭체, 즉 약간 기울인 글꼴을 통해 추상이라는 속성을 가졌음을 표기해준다.


3. 필드값을 적는다. 

  스태틱의 경우, 필드값 아래 밑줄을 친다.

  만약 필드 값이 없다면 공란으로 비워둔다.


4. Method를 적는다.

  스태틱의 경우, 필드값 아래 밑줄을 친다. 

만약 메소드가 없다면 공란으로 비워둔다.



다음 예제를 살펴보자.


Ex) Executable 인터페이스를 UML 다이어그램으로 표현하기


interface Executable{

abstract void execute();

}



- 정답





- 그리는 순서

 1. 클래스 다이어그램을 그린다.

 2. 인터페이스 Executable임을 표기한다. 

 3. execute를 그린다.


와 같은 절차로 완성되었다.






이번엔 추상클래스를 그리는 예제를 살펴보자.


Ex) ParentClass를 UML 다이어그램으로 표현하기


abstract class ParentClass {

int _field1;

static int FIEELD2;


abstract viod method1();

void method2(){

... 

}


static void method3(){

     ...

}


}



- 정답 : 


( method1은 추상메소드이므로 속성에서 isAbstract를 클릭해주면 된다)


- 그리는 순서

 1. 클래스다이어그램을 그린다.

 2. ParentClass는 추상클래스임을 표기해준다. 

 3. 필드값들을 입력하고, FIELD2는 static임을 표기한다.

 4. method들을 이력하고 method1은 static임을 표기하고, method3은 static임을 표기한다.


와 같은 절차로 완성되었다.



starUML을 통해 클래스 다이어그램을 그리는 것을 알아보았다.


다시 한번 정리하자면,


이탤릭체로 표기해야 하는 것은 추상클래스명/인터페이스명/추상메소드이며

밑줄은 static의 속성을 가질 때 그어주면 된다는 것이다.


다음 글에서는 클래스간의 관계 표기에 대해 알아보겠다.








예제 출처 : 자바로 배우는 리팩토링 입문





'IT 지식 > 공통' 카테고리의 다른 글

일반화와 상속의 차이  (1) 2018.01.07

can / can't 의 구분


can't 는 세게 강조해서 발음을 하는 것이 좋다.

can 은 가볍게 빠르게 넘어간다. 그래서 리스닝 공부를 하다보면 I can이 아이큰이라고 들리기도 한다.



These days, i can't decide which one to buy. -> 요즘엔 어떤 걸 살지 결정을 못하겠어. (결정장애가 왔는데, 결정하는 것이 불가능.)

=>i'm struggling to decide which one to buy.



또한, 면접볼 때 되도록이면 can't 처럼 의지를 가지고 할 수 없다고 표현하는 대신 it is hard for me to ~ 를 쓰는 것이 낫다.

'영어 > 영어회화' 카테고리의 다른 글

could / would  (0) 2018.01.12
점심거리 사러갈 때  (0) 2018.01.11
발표 주제정하기  (0) 2018.01.07
should / have to / must / be supposed to  (0) 2018.01.03
3인칭 단수 주어  (0) 2018.01.03

should / have to / must / be supposed to



1. should


[Suggestion]

권장 / 좋을 것 같아

I should go to work this Sunday. 

나 이번 주 일요일 출근해야해 (X) -> 당직이라면 have to or must 를 써야한다. 

나 이번 주 일요일 출근하면 좋을 것 같아.


shouldn't 개인적인 충고에서 나오는 조언을 쓸 때 사용. ~하지마.


2. have to


[의무] ~해야 한다. 


don't have to ~ 할 필요없어


3. must


~해야만 한다.

You must follow this rule.


4. be supposed to


[책임] 기준(상식 혹은 관례, 규정)에 따라 해야한다.

be not supposed to 기준에 따라 하면 안된다.


I'm supposed to be in Hongdae by 3 o'clock today. 3시까지 홍대에 가기로 했어.


만약, be not supposed to 라면 하면 안된다라는 뜻이므로

You're not supposed to change the password. 너 패스워드 바꾸면 안돼! 라는 뜻이 된다.

'영어 > 영어회화' 카테고리의 다른 글

could / would  (0) 2018.01.12
점심거리 사러갈 때  (0) 2018.01.11
발표 주제정하기  (0) 2018.01.07
can / can't  (0) 2018.01.03
3인칭 단수 주어  (0) 2018.01.03

3인칭 단수 주어


- 3인칭 단수

1. She/He : she lives in Seoul.

2. It : It has legs.

3. This/That

4. The company

5. Youngbin / Minji 등



'영어 > 영어회화' 카테고리의 다른 글

could / would  (0) 2018.01.12
점심거리 사러갈 때  (0) 2018.01.11
발표 주제정하기  (0) 2018.01.07
can / can't  (0) 2018.01.03
should / have to / must / be supposed to  (0) 2018.01.03

시스템 엔지니어


제 4차 산업혁명의 10대 기술 중 하나인 클라우드는 IT 업계에 많은 변화를 불러일으키고 있습니다. 웹사이트에 접속해 클릭 몇 번으로 누구나 쉽고 빠르게 서버를 구축할 수 있고 웹앱을 통해 쉽게 서버에 어플리케이션을 더해 서비스하는 세상이 된 것입니다.


즉, 이 말은 하드웨어 의존성이 낮아지며 소프트웨어화됨을 뜻하게 됩니다. 4차 혁명은 바로 소프트웨어파워다라는 말을 실감할 수 있습니다. 저는 따라서 시간이 흘러 클라우드 서비스가 정착되면 SE 쪽의 상당수 인력이 소프트웨어로 대체될 것이라 조심스레 예상해봅니다.


그러나 클라우드 서비스가 등장하였다고 하여 학문적 지식이 필요가 없어지는 것이 아닙니다. 클라우드 상에서 일어나는 문제를 해결할 수 있으려면 관련된 지식이 꼭 필요하기 때문입니다. 


그렇다면 시스템 엔지니어란 어떤 일을 하는 직업일까요?

시스템 혹은 솔루션이 원활히 운영될 수 있도록 셋팅부터 운영 상의 이슈를 해결하고 모니터링하는 일련의 제반작업들을 하는 엔지니어를 뜻합니다.


참고적으로 회사마다 엔지니어링의 범위가 상이가 할 수 있습니다. 그러나 기본적으로 서버를 다룬다는 공통점이 있습니다.

따라서 서버 상에서 발생할 수 있는 다양한 이슈들을 확인하고 해결할 수 있는 다음과 같은 능력이 요구되어집니다.


시스템 엔지니어로서 요구되어지는 능력

 1. 운영체제에 대한 이해

 2. 네트워크에 대한 이해

 3. 보안에 대한 이해

 4. 영어 실력


[시작전 ] 상태파악하기


시험은 10월 22일. (21일인 건 아니겠지?)

아무튼 약 17일 남음.


파워쉘 스크립트랑, VB만 끄적거리다가 오랜만에 C와 C++을 하려하니 아무 것도 기억이 나지 않았다.


어제 몸풀기로 몇개를 시도해봤는데, 아스키 코드 출력하는 것도 %d와 %c를 반대로 썼다. 

스택도 기억이 어렴풋이 나고, int main(){ } 을 빼먹는 다던가ㅋㅋㅋㅋ printf();를 어떻게 쓰는 건지 헷갈렸다.


결론적으로 이 상태로는 "잘 못 하겠다."이다. 코딩을 오랫동안 안해봐서 기억이 안난다. 변명이든 아니든 많이 까먹고 헷갈리고 잊어버렸다는 것이 문제다.

백지상태면 몰라도 애매하게 기억나니까 아는 것이 뭐고 모르는 것이 무엇인지를 모르겠다.


--------------------------------------------------------------------------------------


0. 목표설정


dovelet.com


일단 영빈이가 가르쳐준 사이트이다.

계단이라는 것은 스텝을 의미하는 것 같다.


일단 나는 1단계 ~ 5단계를 최대한 다 풀어봐야할 것 같다.


이후는 영빈이가 짜줬다.

 

9단계 1개

12단계 2~3문제

15단계 1~2문제

16단계 graph 문서보고 dfs 해보기

21단계 문서보고 DP 처음부터 5개 풀기



CMTrace



Task Sequence 실행 중 에러발생시 smsts.log를 분석한다.

로그 분석을 위해 smsts.log를 이동식디스크에 copy하여


CMTrace로 오픈하면 


cmtrace에 대한 이미지 검색결과

<사진출처 구글>


위와 같이, 에러부분을 아름답게 빨강 또는 노랑으로 구별해줘서 편하게 원인분석을 할 수 있다.


The following URL you can download: 

https://www.microsoft.com/en-us/download/details.aspx?id=50012

+ Recent posts