생각하며, 꾸준하게

이젠 OOSAD Analysis의 마지막 단계로 Behavioral(Dynamic) Modeling을 할 차례이다.(iterative가 기본이니 마지막이라고 하긴 좀 그렇긴 함) Behavioral model은 Structural Modeling과 마찬가지로 시스템을 내부에서 바라본다. 마찬가지로 Requirements, Use-Case, 이전 Model들(요구사항, use-case diagram, class diagram)을 기반으로 한다. 특정 기능이 어떻게 이루어지는지 보여준다. 주의할 것이 있는데, 절대 구현을 생각해선 안된다. 구현은 아직 뒤뒤 단계이다. 구현을 생각하는 순간 분석/디자인에 영향을 끼칠 수 밖에 없고, 그러면 우리가 고생해서 한 분석의 재사용이 어려워진다. analysts는 Pr..

IEEE 754와 부동소숫점, 10진수2진수 변환 등을 다룬 글 > 시간나면 꼭 한번 읽어보기 : What Every Computer Scientist Should Know About Floating-Point Arithmetic 실수를 나타내는 방법 중 Scientific notations이란 것이 있다. 소숫점 왼쪽에 숫자가 하나만 있는 경우를 말한다. ex) 2.17x10^6, 0.7x10^(-1) 이런 Scientific notations 중 소숫점 왼쪽에 0이 아닌 숫자가 오는 경우를 Normalized 됐다고 한다. 이진수로 표현된 실수를 모두 Normalized form으로 변경하면 모두 아래와 같이 정형화(?)된다. 우리는 모든 실수를 위와 같이 표현할 수 있는 것이다. 어떻게 저장할까? ..

앞서 Chapter 2까지는 interger에 대해서만 다뤘다. 이번 챕터에선 연산을 좀 더 깊이있게 다룬다. Addition and Subtraction 컴퓨터에서 덧셈은 그냥 사람이 계산하는 것처럼 계산한다. carry가 생기면 올려버리고,, 대신 2진수로 한다는 점이 좀 다르다. 또 음수는 2의 보수로 표현해서 덧셈으로 진행된다. 그리고 비트 수가 제한돼있어서 올라가는 carry가 비트수를 넘어가면 그냥 버려진다. 이렇게 연산결과가 hardware로 표현할 수 없는 경우를 overflow라고 한다. 2의 보수 인 경우 Overflow Detection 1. 덧셈에서 서로 다른 부호를 연산하면 절대 overflow가 발생하지 않는다. 2. 뺄셈에서 서로 같은 부호를 연산하면 절대 overlfow가 발..

directory 내의 files을 출력하는 ls를 구현하기위해선 우선 directory가 무엇인지 알아야한다. UNIX/LINUX에서 "file"은 byte들이 모인 것일뿐이다. 어떤 프로그램으로 해석을 하느냐가 그것에 의미를 부여할 뿐이다.(매우 당연한 관점같지만 UNIX에서부터 시작된 것이다.) LINUX에선 directory도 file로 취급한다. directory file엔 해당 directory 내부 정보나 다른 하위 directory 정보가 담긴다. 각 directory들은 tree구조로 엮인다.(뭐 node만들어서 엮고 하는 그런 특별한게 아니라 그냥 하위 directory 정보를 포함할 뿐이지 상위 directory 정보를 포함하진 않으니 tree 구조란 얘기인듯) 이제 System Ca..

이전까진 functional modeling에 대해 봤다. 이번엔 structural modeling에 대해 배운다. 실제 코드로 옮겨지는 상당 부분이 이 structural modeling때 결정된다. 구현할때 나머지 functional/behavioral modeling도 도움을 준다. Functional models는 system behavior에 초점을 맞췄었다. Structural models는 System Objects와 그들의 relationships에 초점을 맞춘다. 이것이 디자인을 거쳐 코드까지 연결된다. Functional modeling은 외부 관점에서 시스템을 바라보지만, Structural model은 시스템 내부에서 "System Object(세부 사항 포함)"와 "그들 사이 관..

OOAD랑 뭐랑 뭐 자꾸 헷갈리는데 다시 정리하고가자면, SDLC는 일단 4단계로 나뉜다. 그 단계의 배치가 어떻게 되냐에 따라 방법론이 나뉘기도 하지만, data/process 어디에 집중할지에 따라 방법론이 나뉘기도한다. 즉 두 부류의 방법론들은 서로 덮어씌우지는(?)거다. OOAD이면서 agile일 수도 있고, parallel일 수도 있는 것이고.. 지금은 그냥 SDLC 각 단계들을 OOAD 특성을 살려 배워 나가는 것 같다. (use case, 반복/점증, functional/structural/behavioral 이라는 특성들을 각 단계에서 적소에 써가며...) (마지막에 다 하고나야 좀 제대로 감이 잡힐 것 같긴하다. 이거도 맞는지모르겠네. 이론만 배우니 뜬구름 잡는 것 같음) 이전까지 req..

컴퓨터의 언어로 쓰인 단어를 instructions라고 하고, 그 vocabulary를 instruction set이라 한다. 사람이 읽을 수 있는 instruction과 기계가 읽을 수 있는 instruction, 두가지 형태를 가진다. 기계어 형태, assembly어 형태 이런 instruction set이 바로 hardware와 software 사이 interface이다. Instruction은 Opcode(operation code)와 Operands 두가지 부분으로 나뉜다. Opcode에 따라 Operands에 연산을 수행하는 것이다. Instruction set이 computer마다 다른 것은 맞지만, 그렇게 다르진 않다. 왜냐하면 모든 computer는 비슷한 하드웨어 기술로 만들어지고, 제..

공통 집합의 hardware technologies가 computers에 사용되지만, 종류는 크게 3가지로 나뉜다. 1. Personal Computers (PCs) 2. Servers : 주로 network를 통해서만 접근된다. 3. Embedded Computers Post-PC Era Personal Mobile Device(PMD)가 급증해 PC를 대체해나가기 시작했다. 요즘의 PMD는 smart phone이나 tablet computer이지만, 이후엔 electronic glasses가 될지 모른다. 기존의 Server를 대체하는 놈도 등장하기 시작했는데, Cloud Computing이란 것이다. Cloud Computing은 Warehouse Scale Computers(WSCs)라는 큰 da..

(설계과목이니 planning을 주로 다루는 chapter 2는 건너뛰겠다고 하심) SDLC 중 Analysis 단계에 해당한다. 용어 as-is system == current system to-be system == new system Requirement Determination Requirement : system이 해야하거나 가져야하는 특성을 문장으로 기술한 것으로, 나중엔 어떻게 구현될지 technical description으로 자세하게 바뀌어야한다. Requirement는 use-case를 파악하는 것은 물론, 이후 다양한 분석 과정에서 기반이 되는 자료이다. 아래 설명하는 다양한 방식으로 Requirements를 최대한 많이 자세하게 수집하고, 나머지 analysis 과정은 모두 이 re..

과거 프로그래머들은 큰 계획없이 바로바로 프로젝트에 착수했다. 그만큼 규모도 작았고, 필요성을 크게 못느끼던 시기였다. 지금은 규모가 매우 크니 구현전 설계는 필수이다. 그리고 설계를 하더라도 (책의 자료에 의하면) 1996년 조사에서 53퍼센트의 IS project가 완성전에 버려졌다. 완성되더라도 계획보다 비용이 커지거나 시간이 길어지거나 구현이 덜 되었을 수 있다. 등등등... 즉, 지금은 제대로 설계를 해도 모자랄판이다. system analyst는 이런 프로그램 설계를 총괄하기도하지만, 그 외적인 요소도 신경쓰는 사람이다. 고객과 제대로 의사소통해 원하는 것을 파악해야하고, 시스템 설계도 당연히 잘 해야하며, 무엇보다 본인이 속한 조직에 가치있는 것을 만들어야한다. 여기서 가치있는 것이란, 사기..