노는 게 제일 좋아

세마포와 모니터의 사전 이해가 필요하다. [컴퓨터(Computer Science)/운영체제(Operation System)] - 동기화, 세마포 : Synchronization, Semaphores [운영체제] [컴퓨터(Computer Science)/운영체제(Operation System)] - 동기화, 모니터 : Synchronization, Monitor 사실 나는 생산자-소비자 문제로 알고 있었다. 생산자가 데이터를 생산하면 소비자는 그 데이터를 소비하는 형태의 문제이다. 산한 데이터는 중간의 버퍼,buffer 에 저장해두고 소비자는 여기서 필요한 만큼 가져간다. 버퍼의 크기는 유한해서 버퍼 공간 크기 이상의 데이터를 저장할 수 없고 소비자는 버퍼가 비어있다면 가져올 수 없다. **유한한 버퍼의 ..

이제야 정말 UML로 모델링을 해보려고 한다. UML에 대해서 알아보자 UML이란 Unified Modeling Language로 객체지향 모델을 표현하는 방법 중 하나이다. 다시 말하면 객체지향 소프트웨어를 모델링 하는 표준 그래픽 언어라고 할 수 있다. ++UML은 객체지향 설계 표현방법의 표준으로 알려져있다. UML은 시스템의 설계 뿐만 아니라 시스템의 여러가지 측면을 모델링하여 나타낼 수 있다. 클래스를 상세히 기술하는 것만은 이해하기 충분하지 않다. 모델링으로 여러 클래스가 어떻게 연관되어 있고 필요한 기능을 제공하기 위하여 어떻게 상호작용 하는지 이해할 수 있다. UML은 이를 가능케 한다. 위의 그림처럼 표현하는 방식이다. 그렇다면 저 오른쪽 UML 그림은 뭘까? 역시 그림이 제일 이해하기 ..

계획 다 했으니 이제 정말로 형태를 갖춰가는 작업을 해야지?? 그게 모델링이다. 형태를 만드는 것 모델링이란 도메인 지식을 체계화 하는 과정으로 중요한 도메인 개념과 특성, 관계를 파악하여 다이어그램으로 정형화하는 것이다. 모델링은 개발팀이 응용 문제를 이해하는 데 도움을 주는 일종의 개념화 과정이다. 요구 추출과정에 의하여 수집된 도메인 개념과 정보는 분석되고 분류되어 UML과 같은 방법을 이용하여 모델로 비주얼화 된다. 모델링이 구체적으로 어떻게 개발자에게 도움을 주느냐? 1. 응용문제를 이해하는 데 도움을 줌 2. 개발팀원들 사이에 응용문제의 공통 개념으로 대화하게 하고 개선시킴 3. 파악한 개념을 사용자와 고객에게 전달 할 때 도움을 줌 4. 후속 작업 즉 설계, 구현, 테스팅, 유지보수에 개념적..

도메인 분석은 문제의 배경을 알고자 하는 것이다. 또한 도메인은 시스템을 모델링하기 위한 개념적 프레임워크를 제공한다고 했다. 다시 말해서 도메인 분석 자체는 모델을 만드는 것은 아니다. 모델링을 위한 개념 이해화 정보 추출 작업일 뿐이었다. 우리는 모델링 하기 전 단계인 사용사례와 액터를 알아봐야 한다. 사용 사례란 시스템이 수행할 것으로 기대되는 기능을 말한다. 시스템 사용자에게 서비스를 제공하기 위한 상호작용의 단위로도 쓰인다. 다시 말해서 사용자 또는 외부 시스템이나 기타 요소들이 시스템과 상호작용 하는 다이얼로그를 모델링 한 것이다. ex) 현금인출기의 현금 인출 시스템과 주고 받는 이벤트의 기록 == 사용사례 사용사례는 사용자와 시스템 설계자/테스트 프로그래머들이 의사 교환하는데 유용하게 쓰인..

요구분석을 살짝 맛봤다 근데 항상 중요한게 문제도 중요하지만 문제가 생기게 된 배경을 아는 것도 중요하다 그래서 도메인에 대해서 알아보려고 한다. 도메인이란 간단히 말해서 요구의 배경을 말한다. 소프트웨어를 구축할 때 문제 자체도 중요하지만 문제가 어디에 놓여있는가도 중요하다. 즉 문제의 배경을 말한다. 도메인을 분석하는 이유는 설계 모델링에 필요한 여러 개념과 비즈니스 파악을 위함이다. 이러한 사항을 깊이 이해하지 않고서는 제대로 된 설계를 할 수 없다. 도메인 분석에서는 응용 분야에 존재하는 개념을 잘 정의하고 분석해서 시스템에 존재하는 개념으로 정립하는 단계 다시 말해서 도메인 분석이란 요구의 배경을 이해해서 개발될 시스템을 설명하는 개념을 발견하는 과정이다. 그래서 앞서 문제의 범위를 정했듯이 여..

일반적으로 6가지로 나눌 수 있다. 위의 그림같이 일어난다. 용어부터 설명하자면 Caller는 callee를 부르는 주체 -> 함수를 부르는 routine을 말함. Callee는 Calling을 당하는 대상 -> 불려지는 함수를 말함 1. 메인 루틴에 $a0부터 $a3까지 argument register에 해당 파라미터를 가져다 놓음 -> 4개의 레지스터이므로 최대 4개까지의 파라미터를 보낼 수 있음. (Callee가 이용할 수 있게) 2. Caller가 Callee에게 제어를 넘김 -> 즉 Caller 루틴이 멈추고 Callee 가 실행된다는 말이다. 3. Callee가 실행되면 Callee가 필요한 자원들을 받기 위해 메모리를 할당 받는다. (보통 stack에 할당) 4. Callee 본연의 역할 수..

요구 분석 단계의 전반적인 측면을 알았다면 요구 추출에 대해서 알아보자 요구 추출이란 소프트웨어 개발에서 특별히 중요한 작업으로 사용자가 무엇은 원하는지 결정을 내리는 작업이며 여러가지 기법을 통해서 얻어진다. 요구 추출에는 세 가지 단계의 작업이 필요하다 1. 응용에 대한 정보 출처 파악 2. 응용에 대한 정보 취합 3. 요구와 제한 사항의 정의 요구 추출은 응용 분야에 대한 정보를 모으는 것부터 시작된다. 그러한 요구 추출을 위한 정보를 모으는 방법 또한 여러가지다. 고객의 발표 문헌 조사 업무 절차와 양식 조사 관련자들 설문지 사용자와의 인터뷰 브레인 스토밍 회의 사용 스토리 또는 사용사례 작성 위 방법을 통해서 정보를 모은다. ++위 방법을 통해서 얻은 요구는 우선순위로 나누면 좋다. 1. 절대적..

이제 계획은 다 세웠으니까 실제로 프로젝트를 진행해봐야겠지? 그러면 이제 고객의 요구(requirement)가 뭔지를 분석해야 요구에 맞는 소프트웨어를 개발하겠지? 그래서 이번엔 요구분석에 대해 알아보려고 한다. 요구 분석이란 새 시스템이나 변경할 시스템의 요구를 결정하는 작업으로 개발자, 관리자, 사용자 모두가 참가해서 서로의 상충되는 요구를 조정하는 단계이다. 이 단계를 잘못하면 프로젝트를 완료해도 망한 소프트웨어가 나올 게 뻔해지니까. 정말 중요한 단계다. 실제로 개발의 첫 단계로 요구 분석을 진행한다. 요구 분석은 다시 두 가지 단계로 나뉜다. 분석 단계와 요구 명세서 작성 단계 분석 단계에서는 현재 상태를 파악하고 요구를 정의하고 문제 해결과 구현될 시스템의 목표를 도출한다. 명세서 작성 과정에..

비용, 일정 예측도 했으니까 이제 누가 할 지를 짜야겠지? 그렇다면 팀은 어떻게 짤지 알아보자 축구팀 짜듯이 그냥 엎어라 뒤쳐라 하면 될까? 묵찌? 그렇게 하면 프로젝트 작살난다. 개개인의 역할을 정의하고 프로젝트에 적절히 할당해서 목표를 이뤄야한다. 비용, 일정 다 잘 예측해도 사람을 제대로 배치 안하면 망한다. //경찰한테 집에 불난 것 끄라하면 제대로 하겠나? 소방관한테 맡겨야지 그래서 서로 협력도 잘하고 상호 작용도 잘 이뤄지게 팀을 짜야한다. 각설하고 소프트웨어 개발은 조금 다른 특징을 가지고 있어서 조직 구성 방법에 따라 품질이 달라질 수 있다. //축구 포메이션이랄까? 선수는 같아도 포메이션 마다 성적이 다른 느낌?? 팀을 구성하는데 고려할 점을 살펴보자 그 후 방법을 살펴볼 것이다. 1. ..

그렇다면 이제 진짜로 일정, 날짜 같은 것을 예측해야겠지? 출시 예정일 같은 것들을 알아야 광고도 찍고 홍보도 하지 그래서 이번엔 스케줄링을 알아보려고 한다. 일정 계획(Scheduling) 개발할 소프트웨어의 규모와 인력 총량이 결정되었으면 이제는 상세한 일정을 잡아야한다. 개발 프로세스를 이루는 소작업들을 파악해서 소작업들의 순서와 일정을 정하는 일, 바로 스케줄링이다. 다시 말해서, 개발 프로세스 모델을 결정하고, 소작업, 산출물, 이정표들을 설정하는 과정이다. 일정계획은 간단하게 4단계라고 말할 수 있다. 1. 작업분해 (Work Breakdown Structure) 2. CPM (Critical Path Method) 네트워크 작성 3. 최소 소요 기간을 구함 4. 간트 (Gannt) 차트 도출..