생각하며, 꾸준하게

Physical Architecture Layer Design도 requirements가 가장 기본이다. 특히 non funcitonal Requirements를 기초로 디자인한다. 우선 Physical Architecture Layer Design의 기본 요소들을 알아보고, 글의 마지막쯤에 어떤 requirements일때 어떻게 설계하는게 좋은지 알아본다. 대부분의 현대 System들은 한 컴퓨터에만 존재하는게 아니라 network를 통해 여러 computers에 분산돼있다. (그냥 한 컴퓨터 안에서만 돌아가는 standalone system은 요즘 찾기 어렵다.) Physical Architecture Layer는 다음을 명시하는 layer이다. 1. 이전 단계들에서 만든 System의 SW 부분을 ..

지금까지 PD Layer에 집중했는데, 이 글에선 HCI Layer, 특히 그 중에 GUI에 대해 집중적으로 알아본다. 초반에 Analysis 단계에서 Use-Case Diagram에서 actor와 use-case 사이에 그려졌던 선들은 System의 Interface를 의미한다. User actor와 연결된건 user-Interface를 의미하고, 외부 system actor와 연결된건 system-interface를 의미한다. Use Case를 사용하려면 PD와 User 사이에 interface가 필요하다는 말이다. Interface Design은 우리가 만드는 system이 어떻게 외부와 어떻게 상호작용할지를 정의한다. 머신간의 interface인 (1)System Interface와 머신-사람 i..

어떤 Layer든 Class와 Method Design은 기본으로 들어가있다. 이런 Class/Method를 Design하는 것에 대해 자세하게 알아보자. 구현전에 Design은 무조건 선행돼야한다. Design Criteria design을 평가하기위한 몇가지 방법?이다. 1. Coupling : class/object/method들간에 가까운 정도를 판단한다. classes간에는 간단하게 message를 보낼 수 있나, 즉 association관계에 있나로 판단한다. 낮아야 좋다. 2. Cohesion : 한 class의 attributes나 methods가 단일 object를 지원하는지 확인해야한다. general하게 말하자면 Class든 Method든 같은 개념을 말해야 cohesion이 좋은 것..

앞서 과정까지 우리는 분석을 위해 requirements를 기반으로 여러 Analysis 모델을 iterative/incremental하게 만들었다. 분석에서 business needs를 정했다면, 디자인에선 어떻게 system을 만들지에 집중한다. 분석 과정을 통해 우리가 만들/보완할 system이 어떤 기능을 어떤 흐름으로 해야하는지, 내부구조가 어떻게 되는지, 각 class/object들이 어떻게 상호작용하는지를 알았다면,, 이제는 구현으로 넘어갈 수 있도록 Analysis 모델을 Design 모델로 발전시켜나가야한다. (특히 Class D를...) 이 글에선 그런 Design 과정의 전체적인 흐름을 보도록 하겠다. Design 과정의 특징은 다음과 같다. 1. 구현을 위한 청사진을 제공한다. 2...

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

이전까진 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..

(설계과목이니 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는 이런 프로그램 설계를 총괄하기도하지만, 그 외적인 요소도 신경쓰는 사람이다. 고객과 제대로 의사소통해 원하는 것을 파악해야하고, 시스템 설계도 당연히 잘 해야하며, 무엇보다 본인이 속한 조직에 가치있는 것을 만들어야한다. 여기서 가치있는 것이란, 사기..

교수님께서 한번 읽어보라고 올려주신 자료인데, 내용이 괜찮아 한번 정리해볼까한다. 내가 이해한대로 예를 들어가며 작성했다.기존에도 Smalltalk나 Simula programming language에 object-oriented라는 개념은 있었으나, 1980년대에 processor power가 증가하고 비용이 감소하기 전까지 그리 실용적인 개념은 아니었다. 현재는 다양한 programming language(C++, Java, Objective-C, Python, ...)에서 object-oriented 개념을 각각 다른 방식으로 구현한다. 여기선 object-oriented system의 기본 특성인 class, object, method, message, encapsulation, informati..