다양한 기록

액터개발중인 시스템과 상호작용을 하는 시스템 외부의 존재- 사용자 액터- 외부 시스템 액터- 장치 액터 유스케이스- 시스템이 제공할 기능적 단위 액터와 유스케이스 간의 관계- 특정 기능을 위하여 어떤 액터들이 상호작용하는지 표현관계표기법의미Association클래스 A와 클래스 B는 연관 관계를 가지고 있다.Composition클래스 B는 클래스 A의 부분이다.Generalization클래스 B는 클래스 A의 하위 클래스이다.Dependency클래스 A는 클래스 B에 의존한다.Interace 실현 관계클래스 B는 인터페이스 A를 실현한다.Interface 의존 관계클래스 A는 인터페이스 B에 의존한다. - : priavate+ : public/ : 직접 입력되는게 아니라 다른 값들에 의해 계산되는 값 인..

모델과 모델링 실체(reality)시스템(project)= 모델링 > 모델 (model).. 요구사항 모델, 분석 모델, 설계 모델 실체(reality) : 실제 개발되어야 하는 시스템모델(model) : 실체에 대한 표현모델링(modeling) : 실체로부터 모델을 구축하는 활동구현 (implementation) : 모델을 바탕으로 실체를 구축하는 활동 필요성시스템이 복잡하니까 모델로 만들어서 간략화하고 함축적으로 표현함개요소프트웨어 개발 모델링 (modeling)- 실질적인 시스템에 대한 모델을 구축하는 활동- 요구사항 정의, 분석, 설계를 수행- 각 활동의 결과물은 시스템의 특정 측면에 대한 모델 구현 (implementation)- 실질적으로 동작하는 스템을 구축  UML(Unified Model..

클래스- 객체 유형은 객체의 범주- 클래스는 객체 유형의 소프트웨어 구현- 클래스는 객체들의 집합- 클래스는 각 객체에 적용되는 데이터 구조와 연산을 포함 인스턴스- 인스턴스는 클래스에 속하는 객체임- 클래스의 모든 인스턴스는 동일한 속성과 메소드 집합을 가짐 생성자- 클래스 이름과 동일한 이름을 가진 메소드로 인스턴스를 생성 소멸자- 생성자의 반대로 생성된 객체 인스턴스를 메모리로부터 제거- 객체가 제거되면 자동적으로 수행됨 클래스 변수- 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)- 성능 좋은 데스크탑, 객체지향 기술- 예측 시스템, 인공 뉴럴..