다양한 기록

클래스- 객체 유형은 객체의 범주- 클래스는 객체 유형의 소프트웨어 구현- 클래스는 객체들의 집합- 클래스는 각 객체에 적용되는 데이터 구조와 연산을 포함 인스턴스- 인스턴스는 클래스에 속하는 객체임- 클래스의 모든 인스턴스는 동일한 속성과 메소드 집합을 가짐 생성자- 클래스 이름과 동일한 이름을 가진 메소드로 인스턴스를 생성 소멸자- 생성자의 반대로 생성된 객체 인스턴스를 메모리로부터 제거- 객체가 제거되면 자동적으로 수행됨 클래스 변수- static => 메모리에 미리 올라옴.. BSS 세그먼트- 객체들 간 공유함 클래스 메소드- static 선언- C#이나 자바는 Main이 static으로 선언되어 있어야 함- 메소드를 실행하려면 객체를 만들어야 하는데 맨 처음엔 그런게 없음=> static으로 런..

Encapsulation (캡슐화)- 데이터와 연산의 번들- 관련된 것들을 함께 묶음 Information Hiding (정보 은폐)- 객체를 하나의 Black box 취급- 일부는 완전히 은폐, 일부는 공개- 객체의 사용자들은 공개된 인터페이스를 통해서만 객체에 접근 가능- 숨겨진 데이터에 대한 직접 접근은 허용되지 않으며 오류를 발생시킴 Abstraction (추상화)객체지향의 특성은 어디는 정보 은폐, 어디는 추상화라고 함비슷하면서도 다른 개념추상화는 어찌보면 요약이라고 생각할 수도 있고, 말 그대로 추상적인, 대략적인 표현이라 볼 수도 있음- 상위 클래스에서 추상 메소드만 정의해두고 서브 클래스에서 정의하는 것도 추상화- 내부를 안보이게 해서 요약한다고 이해하는 것도 가능 접근 지정자(visibi..

Observations- 1970's .. 구조적 프로그래밍- 1980's .. 구조적 프로그래밍 -> 객체지향 프로그래밍 전환- 1990's .. 완전한 객체지향 프로그래밍- 2000's .. WWW와 EC를 위한 객체 기술- 현재 .. CBD (Component Based Development)와 소프트웨어 공장 역사Root: SIMULA (1966)- 클래스의 개념 제시 SMALLTALK (1970 ~ 1980)- 클래스 라이브러리 등장 AI Community (1980's) Programming Language Community (1980's)- Abstract Data Type, Encapsulation- Alphard, CLU, ADA객체 지향의 개념 객체 지향 기술- 소프트웨어를 개발하고 패..

1. 일정이 늦어지면 더 많은 프로그래머를 쓰면 된다현실: 조정 작업 증가, 속도 더 늦어질 수 있음-> 추가된 프로그래머의 역량에 따라 달라짐 2. 목표 서술만으로 프로그램 작성 시작에 충분목표는 시작하기엔 좋지만 충분하지 않다초기 정의가 불완전한 것은 소프트웨어 프로젝트 실패의 주요 원인 3. 프로그램을 작성하고 작동되기만 하면 작업 끝문서화, 테스트 기록, 프로그램 설정은 배포의 중요한 부분임 4. 프로그램이 실행될 때 까지는 품질을 평가할 방법이 없다설계 과정 중 리뷰를 통해 가능 5. 좋은 소프트웨어 개발 프로세스와 표준을 따르면 좋은 소프트웨어가 보장된다성공 보장은 못함 6. 프로젝트 요구사항은 계속 바뀌지만 소프트웨어는 유연하기에 변경을 쉽게 수용할 수 있다변경 수용의 용이성은 변경 요청이 ..

소프트웨어의 변화가 비즈니스보다 느리면?=> 그만큼의 리스크에 처함반대로 소프트웨어의 변화율이 크면 전략적 기회가 생김 Software Crisis- Late Delivery (기간 지연)- Over Budget (비용 초과)- Inconsistent with the specification (명세와 불일치)- Unreliability (비신뢰성)- Too costly to modify or improve (엄청난 유지보수 비용)...하드웨어 발전은 빨랐으나 소프트웨어가 따라가는 속도가 지지부진소프트웨어 위기 왜 소프트웨어 프로젝트가 실패하는가?SW 마인드 부족불충분한 소프트웨어 프로젝트 관리적절한 소프트웨어 공학 스킬 부족 왜 소프트웨어 개발이 어려운가?특성- 복잡함- 유연성 => 수정 가능함이 오히려..

소프트웨어 특성- 안보임- 제조되는 것이 아닌 엔지니어링 됨- 낡지 않음- 테스트 가능- 적합성, 변경 가능성- 복제 가능- 애플리케이션 신뢰성- 오해받기 쉬움 .. => myth of software1950s ~ mid 1960s (The early years)- 배치 접근, 커스텀 SW 1960s mid ~ 1970s mid (The Second era)- 멀티 유저, 리얼 타임, 데이터베이스, 프로덕트 SW 1970s mid ~ 1980s late (The third era)- 분산 시스템, 임베디드 "Intelligence"- 값싼 하드웨어 - 소프트웨어 엔지니어링 시작 1980s late ~ 2000s (The fourth era)- 성능 좋은 데스크탑, 객체지향 기술- 예측 시스템, 인공 뉴럴..

프로그램- 프로그래밍 언어로 쓰인 명령어의 집합 소프트웨어- 프로그램, 데이터와 관련된 문서 소프트웨어 프로덕트- 제네릭 : 다양한 분야의 소비자들한테 팔려고 개발됨- 비스포크 : 특정한 소비자를 위한 맞춤형 Development of SW요구사항 정의요구사항 분석설계( 아키텍처 / 상세 )구현( 개발 / 테스팅 )유지보수 요구사항 정의- 클라이언트의 요구사항들 도출- 고객과의 대화를 통해 파악- 사용자와의 직접적인 소통을 통해 요구사항을 이해 요구사항 분석 (명세)- 클라이언트의 요구사항이 분석되고, 명세 문서의 형태로 표현- 소프트웨어 프로젝트 관리 계획이 작성- 개발자가 요구사항을 해석하여 구체적인 시스템 설계에 반영 설계- 아키텍처 설계-- 프로덕트를 모듈이라고 부르는 컴포넌트들로 분리- 상세 설..

Password Dilemma/etc/shadow         ... => -rw-r-----  root shadow루트 권한이 있어야만 쓰기가 가능하지만 일반 유저도 비밀번호를 바꾸고 싶을 수 있음 Two-Tier Approach운영체제에서 파인-그레인드 액세스 컨트롤 구현 시 과도하게 복잡해짐OS는 세분화된 접근 제어를 위해 확장에 의존권한이 있는 프로그램이 그러한 확장: set-uid 프로그램, 데몬 타입- Deamon in Linux (Services in MS Windows)- Set-ProgramsSet-UID Concept- 유저가 프로그램을 오너 권한으로 실행하도록 허가 RUID (Real) : 프로세스의 실제 오너 아이디EUID (Effective) : 권한을 나타내는 아이디 RUID는..