개발자 끄적끄적

- 모듈과 모듈사이에 관계를 어떻게 설계할 것인가 -> 결합도는 낮게 - Minimise coupling, make routins as independent ad possible(low RE) - Low coupling => well-partitioned - No routine should have to worry about the internal details or another Normal(low) - Data(데이터) - Stamp(스탬프) - Control(제어) -------------------------------"Modularity Line" Poor(high) - Common(공통) - Content(내용) - To routines are normally coupled if : - A C..

- 설계의 기본 원칙 : 응집도(=개별모듈)는 높게 결합도(=모듈관의 관계)는 낮게 - Fundamental principle of SD - A large system should be partitioned into mangeable routines&models - Goal - Routines are as independent as possible - Each routine carries out a single problem-ralted function - Mesures - Coupling and Cohesion - Cohesion is the measure of the strength of functional relatedness of elements within a routine - Element? ..

- 프로세스 여러 개가 동시에 실행되는 것 - 독립적인 프로세스(Independent process) - 다른 프로세스 실행에 영향을 주거나 받지 않는 프로세스 - 협력적인 프로세스(Cooperating process) - 다른 프로세스 실행에 영향을 주거나 받는 프로세스 - 정보 공유 - 계산 속도 향상 - 모듈식 시스템 구성 - 사용자 편의 - 제한된 자원을 공유하기 위해 자주 상호작용 한다 - 상호작용하는 프로세스는 순서에 맞게 실행되도록 동기화 시켜야한다 - 협력적인 스레드들간에 - 공유 데이터를 동시에(concurrently) 조작하면 데이터 불일치(data inconsistency)가 생길 수 있다 - 데이터 훼손 발생 - 데이터 일치(data consistency)를 위해서는 - 협력적인 스..

- 순차 다이어그램은 서비스를 제공하기 위한 객체 간의 상호 작용(메시지 송수신)을 모델링한다 - 클래스 다이어그램이 시스템의 정적 구조를 나타내는 대표적인 모델인 반면에 순차 다이어그램은 시스템의 동적 흐름을 나타내는 대표적인 모델이다 - 순차 다이어그램은 목표 서비스를 제공하기 위해 필요한 객체를 정의하고, 객체간의 메시지 송수신 관계를 시간 순서에 따라 정의함으로써 서비스를 제공하는 과정을 묘사하는 모델이다 - 순차 다이어그램에서 객체는 가장 윗부분에 표현이 되고, 왼쪽에서 오른쪽으로 객체들을 나열한다 - [객체명 : 클래스명] 형식을 이용하여 표기하며 이중 어느 한쪽을 생략하여 표기할 수 있다. - 객체는 박스로 표현하며 밑줄은 생략가능하다.(UML2.X버전) - 인스턴스이름 : 클래스명 - [시..

- 문제나 해결책의 정적인 구조 표현 - 클래스와 그들간의 관계 표현 - 건물을 설계할 때도 평면도, 입면도, 투시도, 조감도 등 하나의 건축물을 다양한 관점에서 표현한다 *유스케이스 다이어그램 - 시스템을 블랙박스로 본다. 즉, 내부 구조는 표현하지 않는다 - UML의 클래스 표현 - 세 부분으로 나누어진 박스로 표현 - 가장 윗부분 : 클래스 이름 중간 부분 : 마시막 부분 : 연산 - 접근제어자 - public(+) : 어떤 클래스의 객체에서도 접근 가능 - protected(#) : 이 클래스와 상속 관계에 있는 하위클래스의 객체들만 접근 가능 - package(~) : 동일 패키지에 있는 클래스의 객체들만 접근 가능 - private(-) : 이 클래스로부터 생성되어진 객체들만 접근 가능 - 속..

- CPU 유후 시간을 줄이기 위한 다중 프로그래밍 - 작업 스케줄링(job scheduling) - 보조저장장치로부터 메모장에 올릴 작업 선택 - 시작 시 혹은 한 프로세스 종료 때마다 - CPU 스케줄링(CPU scheduling) - 메모리에 적재된 작업 중 CPU를 할당할 프로세스 선택 - 자원에 대한 경쟁이 있을 때 경쟁자들 중 하나를 선택하는 과정 - 작업(job) 스케줄링 - 배치 시스템 - 대기중인 배치 작업 중 메모리에 적재할 작업 선정 - CPU 스케줄링 - 프로세스/스레드 중 하나를 선택해 CPU 할당 - 디스크 스케줄링 - 디스크 입출력 요청 중 하나를 선택하여 장치를 사용하도록 - 입출력 장치 스케줄링 - 프린팅 작업 중 하나를 선택해 프린터 장치 할당 - 프로세스들은 실행(CPU..

- 요구사항 분석   - 고객의 문제의 실체를 이해하고 분석하여 분석 모델을 구축   - 설계    - 설계 모델을 통해 고객의 문제를 해결하는 해결책을 표현 - 구현   - 설계 모델을 기반으로 프로그래밍 언어를 통해 소프트웨어(구현 모델) 구축 *분석 모델 : 고객의 요구사항을 모델링 *설계 모델 : 해결책을 모델링 *구현전에 모델링(요구사항분석, 설계 단계 -> 모델링 언어 필요 -> UML(Unified Modeling Language)) - 서로의 해석을 공유해 합의를 이루거나 해석의 타당성을 검토 - 현재 시스템 또는 앞으로 개발할 시스템의 원하는 모습을 가시화 - 시스템을 구축하는 틀 제공 - 대표적인 시스템 모델링 언어   - 제임스 러버 OMT + 야콥슨 OOSE + 부치 OOAD  ..

- 시스템의 일부 측면을 사용자가 경험하게 할 수 있는 도구 - 요구사항에 대한 대화 촉진 - 이해 관계자가 시스템의 요구사항에 대한 공통의 이해 달성 - 요구사항 오류나 누락 식별 - 요구사항 도출/분석/검증 도구로도 사용 - 범위(Scope)에 따른 분류 - 수평적 프로토타입(Horizontal prototype) - 수직적 프로토타입(Vertical prototype) - 충실도(Fidelity)에 따른 분류 - Lo-fi(Low fidelity) 프로토타입 - Hi-fi(High fidelity) 프로토타입 - 수평적 프로토 타입 - 사용자 인터페이스 부분(front-end)만 존재하고 기능 부분(back-end)구현 미비 - 정해진 출력, 오류 처리 미비 - 명확한 요구사항 파악, 요구사항 구체..

- 작업 or 태스크(task)   - 컴퓨터에서 처리하고자 하는 일의 단위 - 멀티 태스킹(multi-tasking)   - 한 시스템 내에서 여러 태스크를 동시 실행하는 기법     - 사용자 입장에서는 동시에 여러 작업을 처리 가능     - OS 입장에서는 여러 태스크를 관리해야하는 부담 -> 프로세스 단위의 실행의 문제점   - 전통적으로 태스크는 프로세스로 구성     - multi-processing - 한 응용 프로그램이 다수의 비슷한 작업을 수행할 필요가 있을 수 있다   - 예 : 웹 서버     - 단일 프로세스로 동작한다면, 한 번에 하나의 클라이언트만 서비스 가능     - 웹 서버에 요청이 들어오면 그 요청을 수행할 별도의 프로세스 생성산다면, 오버헤드     - 좀 더 가볍게..

- 분석된 요구사항을 명확하고 완전하게 기록하는 것 - 소프트웨어 시스템이 수행하여야 할 모든 기능과 시스템에 관련된 구현상의 제약 조건 및 개발자와 사용자가 합의한 성능에 관한 사항 등을 명세 - 최종 결과물 : 요구사항 명세서(SRS : Software Requirement Specification) *SRS IEE-STD-830 : 소프트웨어 요구사항 명세서 국제 표준 - 무엇을 위해 이 문서를 작성했는지를 설명 - 주의) 제품의 용도를 나열하지 말라 - ex) 이 문서의 목적은 웹 게시 시스템에 대한 자세한 설명을 제공하는 것이다. 이 문서에서 시스템의 목적과 특징, 시스템의 인터페이스, 시스템이 무엇을 할 것인지, 시스템이 작동해야 하는 제약 조건, 그리고 시스템이 외부 자극에 어떻게 반응할것인..