'Analysis & Design'에 해당되는 글 7건

  1. 2011.02.22 Product Perspective
  2. 2011.02.21 Context Diagram (1)
  3. 2010.04.20 아키텍처 / 프레임워크 / 플랫폼
  4. 2010.04.14 일반화와 클래스화
  5. 2009.08.07 화이트박스 프레임워크 vs 블랙박스 프레임워크
  6. 2009.07.15 Design Patterns Documentation
  7. 2009.03.07 개발의 첫단계 :: 스펙잡기 (2)
2011.02.22 09:51

Product Perspective

http://www.chris-edwards.org/340/docs/SRS/node11.html

http://socialtapestries.net/snout/documentation/node83.html

http://webmaker.web.cern.ch/WebMaker/UserReq/Section-2-1.html

Trackback 0 Comment 0
2011.02.21 12:41

Context Diagram

Context Diagram

  • A DFD (Data Flow Diagram) that summarizes all processing activity within the system in single process sysbol.
    • Describes highest level view of a system
    • All external agents and all data flows into and out of a system are shown in the diagram
    • The whole system is represented as one process
    • The data flows that pass between the external entities and the system


DFD (Data Flow Diagram)

  • A graphical system model that shows all of the main requirements for an information system: inputs, outputs, processes and data stroage
  • They are primarily used in the systems development process
  • A data flow diagram is often the diagram of choice for modern entities


Guidelines for drawing a Context Diagram

  • List potential external entities (people, places). Look for entities that
    • Give data to the system without explaining the process that creates that data
    • Take data from the system without explaining what it does with that data
  • Establish what flows are sent to and from the system from external entities


[출처] Context Diagram

Trackback 0 Comment 1
2010.04.20 16:38

아키텍처 / 프레임워크 / 플랫폼

- 아키텍처 : 소프트웨어의 주요 설계 구조
 
소프트웨어의 주요 특징들을 결정짓는 주요 설계 구조이다.즉, 소프트웨어의 주요 구성 요소 및 구성, 이들간의
주요 인터페이스, 중요 동작 방식 등 소프트웨어의 주요 특징들을 결정짓는 모든 설계 구조를 포함한다.
소프트웨어의 주요 특징을 결정짓고 소프트웨어 개발에 미치는 영향도 매우 커서 소프트웨어 개발에 있어서 가장 중요한 부분이라고 할 수 있다.지원 프로그램, 라이브러리, 언어, 다른 소프트웨어 구성 요소 등과 같이 구체적인 구현을 포함하지 않는다는 점에서 프레임워크나 플랫폼과는 명확히 구분된다.
 
- 프레임워크 : 소프트웨어 뼈대 구조
 
프레임워크는 다른 소프트웨어 프로젝트가 개발될 수 있는 뼈대 구조이다.지원 프로그램, 라이브러리, 언어,
다른 소프트웨어 구성 요소들을 엮어 주는 소프트웨어 등을 포함하고 있다.따라서, 플랫폼도 프레임워크의 일종이라고 볼 수 있으며, MS사에서 닷넷 플랫폼을 닷넷 프레임워크라고 지칭하는 것도 틀린 것이 아니다.또한, UI 프로그램 개발을 위한 부분 만을 떼어내서 프레임워크라고 할 수도 있다.UI 프로그램 개발을 위한 부분 만으로는 완전한 소프트웨어 실행 환경이 되지 않으므로 플랫폼은 아니지만 프레임워크이다.이러한 점에서 프레임워크와 플랫폼은 다른 경우가 많다.
 
- 플랫폼 : 소프트웨어 실행 환경
 
가장 일반적이면서도 명료한 의미는 "소프트웨어가 실행되는 환경"이다.개발 언어나 개발 환경을 플랫폼에
포함시키기도 하지만 이는 부수적 개념 혹은  확장된 개념에 불과하고, 핵심은 "소프트웨어가 실행되는 환경"이다.
각 프로그램은 아무 플랫폼에서나 실행되는 것이 아니고 특정 플랫폼에서만 실행된다.
일반적으로, O/S는 모두 플랫폼이다. Windows는 윈도우즈 프로그램만을 실행시킬 수 있는 플랫폼이고, 리눅스는 리눅스 프로그램만을 실행시킬 수 있는 플랫폼이다.자바 런타임 환경도 플랫폼이다.자바 프로그램은 O/S에 대한 종속성은 거의 없고 자바 런타임 환경없이는 실행되지 않으므로 자바 런타임 환경을 주요 플랫폼으로서 필요로 한다.마찬가지로 닷넷 프로그램도 닷넷 런타임 환경없이는 실행되지 않으므로 닷넷 런타임 환경이 플랫폼이 된다.AJAX 기술을 사용하여 개발된 웹 컨텐츠 + 웹 클라이언트 스크립트는 웹(좀 더 정확히는 웹 브라우저 및 웹 서버) 없이는 실행되지 않으므로 웹을 플랫폼으로 한다.VBA(Visual Basic for Application) 프로그램과 MS 오피스 COM API를 사용하는 프로그램은 MS 오피스가 없으면 실행되지 않으므로 MS 오피스를 플랫폼으로 한다.
플랫폼은 플랫폼위에 다른 플랫폼을 구축할 수 있는 계층적 구조를 가질 수 있다.가령, 자바 프로그램은 자바
런타임 환경이라는 플랫폼에서 실행되지만 그 플랫폼 자체는 O/S 플랫폼 계층 위에서 실행되는 프로그램에 불과하다.웹 플랫폼에 해당하는 웹 브라우저 또한 O/S 플랫폼 계층 위에서 실행되는 프로그램에 불과하다.VBA 프로그램의 플랫폼인 MS 오피스 프로그램 또한 O/S 플랫폼 계층 위에서 실행되는 프로그램에 불과하다.이들 각 계층의 각 플랫폼은 자신만의 실행 엔진과 API 및 개발 환경을 제공하며, 다른 플랫폼에 대한 부분적 접근을 허용하기도 한다. 또한, 각 플랫폼 내부는 또 다시 여러 계층으로 이루어진 구조를 갖는다.
이는 소프트웨어 구조가 그만큼 계층화되고 복잡해지고 있음을 의미한다.
역설적이지만, 소프트웨어 구조가 이렇게 다양해지고 복잡해지는 이유는 다양하고 복잡해지는 요구를 보다 적절히 만족시키기 위한 효과적인 방법이기 때문이라고 볼 수 있다.
따라서, 각 플랫폼은 나름대로의 가치와 적정 용도가 있으므로 프로그램이 성공적(경쟁 제품, 서비보다 저렴하게 개발하거나 보다 고품질을 제공하는 등)이기 위해서는 프로그램 개발 전에는 개발 목적에 가장 적합한 플랫폼을 선정하고 프로그램 개발중에는 플랫폼의 잇점을 최대한 살리는 것이 중요해진다.
그렇지 않은 제품 혹은 서비스는 경쟁력이 떨어질 수 밖에 없다.
물론, 단순하지 않은 제품/서비스에 적합한 플랫폼의 선정은 다루어야 하는 이슈가  많기 때문에 매우 어려운
문제이다.

 [출처] Devil BBong's Story

Trackback 0 Comment 0
2010.04.14 15:53

일반화와 클래스화

객체지향 이론에서의 클래스화(classification)와 일반화(generalization) 관계를 알아보자.
이 관계를 이해하기 위해서는 먼저 Type과 Object의 의미를 이해해야 한다.

Type과 Object란 무엇인가?

 - Type 은 개념을 의미한다. UML에서는 Class로 표현된다. (= Concept, Class)
 - Object 는 Type이 인스턴스화된 실체를 의미한다.



예를 들어, 우리집에서 키우는 누렁이, 이웃집에 있는 삽삽이는 Object 이고, 이러한 Object들은
개(Dog)라는 Type의 인스턴스이다.


Classification(클래스화)란, Type과 Object 와의 관계이다. 객체들이 특정개념에 속할 때, 클래스화 관계로 나타낼 수 있다. (↔ 인스턴스화, instantiation)


  
Generalization(일반화)는 Type간의 관계이다. 특정개념이 다른개념을 완전히 포함할 때, 일반화 관계로 나타낼 수 있다. (↔ 특수화, Specialization)



Trackback 0 Comment 0
2009.08.07 05:09

화이트박스 프레임워크 vs 블랙박스 프레임워크

프레임워크 도출 3단계



화이트박스 프레임워크(White Box Framework)
  - 구현방식 : 상속(inheritance)이나 동적바인딩(dynamic binding)으로 구현
  - 프레임워크 기능확장 : 1) 프레임워크 기초 클래스(base class)를 상속하거나 2) Template Method와 같은 디자인 패턴을 사용하여 미리 정의된 후크 메서드(hook method)를 재정의(overriding)하는 방식으로 기능확장
  - 단점 : 1) 어플리케이션 개발자가 프레임워크 내부 구조를 잘 알고 있어야 하며 2) 프레임워크 클래스 계층도의 세부사항과 밀접하게
결합되어 유연성이 결여된 시스템을 구축할 가능성이 많아짐

블랙박스 프레임워크(Black Box Framework)
  - 구현방식 : 객체 합성(object composition)이나 위임(delegation)을 사용하여 구현
  - 프레임워크 기능확장 : 프레임워크에서 정의한 인터페이스를 실현하는 컴포넌트를 구현하고, Strategy와 같은 디자인 패턴을 사용하여 이들 컴포넌트를 프레임워크 안에 통합시켜 기능확장
  - 화이트박스 프레임워크 보다 사용하거나 확장하기는 쉽지만 설계하거나 구현하기는 더 어려움



[출처] Kimgisa's IT Story

Trackback 0 Comment 0
2009.07.15 13:13

Design Patterns Documentation

The documentation for a design pattern describes the context in which the pattern is used, the forces within the context that the pattern seeks to resolve, and the suggested solution.[16] There is no single, standard format for documenting design patterns. Rather, a variety of different formats have been used by different pattern authors. However, according to Martin Fowler certain pattern forms have become more well-known than others, and consequently become common starting points for new pattern writing efforts.[17] One example of a commonly used documentation format is the one used by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides (collectively known as the "Gang of Four", or GoF for short) in their book Design Patterns. It contains the following sections:

  • Pattern Name and Classification: A descriptive and unique name that helps in identifying and referring to the pattern.
  • Intent: A description of the goal behind the pattern and the reason for using it.
  • Also Known As: Other names for the pattern.
  • Motivation (Forces): A scenario consisting of a problem and a context in which this pattern can be used.
  • Applicability: Situations in which this pattern is usable; the context for the pattern.
  • Structure: A graphical representation of the pattern. Class diagrams and Interaction diagrams may be used for this purpose.
  • Participants: A listing of the classes and objects used in the pattern and their roles in the design.
  • Collaboration: A description of how classes and objects used in the pattern interact with each other.
  • Consequences: A description of the results, side effects, and trade offs caused by using the pattern.
  • Implementation: A description of an implementation of the pattern; the solution part of the pattern.
  • Sample Code: An illustration of how the pattern can be used in a programming language
  • Known Uses: Examples of real usages of the pattern.
  • Related Patterns: Other patterns that have some relationship with the pattern; discussion of the differences between the pattern and similar patterns.

[출처] 위키피디아

Trackback 0 Comment 0
2009.03.07 23:24

개발의 첫단계 :: 스펙잡기

모든 개발프로젝트를 시작함에 있어 명세서(specification)의 작성은 아주 중요하다. 완벽한(과연?) 명세서를 만든다면 개발프로젝트는 50%이상완료되었다고보아도 좋다.
명세서가 뭐길래 그토록 중요한 것일까?
명세서를 쓴다는 것(혹은, 스펙을 잡는다는것)은 프로젝트의 최종 목표를 정하는 일이고, 목표물이 되기까지 거쳐야 하는 필수 단계들을 나열하는 것이고, 마주칠지도 모르는(아마 거의 마주치게 될) 어려움을 미리 예측하여 어려움의 발생을 최소화하는 유일한 방법이다. 적어도 내가 아는 한은 그렇다.
또, 비교적 지킬수 있는 스케줄링을 하는데 무척이나 기여한다.

우리나라의 대부분의 IT기업들은 보통 스펙을 잡는 과정을 개발과정으로 간주하지 않는다. 이는 기획자의 몫이며 개발자는 기획자가 만든 기획안(이걸 스펙과 혼동한다)대로 구현해 주면 되는 것이라고 생각한다.
그나마도 이렇게 생각해주면 다행이다.

기획자도 없이, 누군가(사장, 혹은 부서장?)에 의해 무언가를 만들겠다고 내던져진 말이 곳 스펙이 되어 버린다. 개발자는 의례 Visual Studio라던지 Eclipse라던지, 터미널에 VI를 열어놓고 높으신 분께서 말한 제품을 어떻게 만들수 있을지 생각한다.

뭔가 이상하지 않은가?
"이러한 소프트웨어가 필요하다"
라고, 단지 필요한 소프트웨어의 대충의 명칭을 말하면 개발자는 알아서 그것은 이런 기능을 가질 것이다 라고 판단하고 자기 머릿속에만 있는, 곳 자기도 기억하지 못할 스펙을 상상해 낸다. 신기하게도 제품은 완성되고, 처음에 프로젝트를 시작시켰던 분께서는...
"훌륭해.. 그런데, 이걸 왜 만든거지?"
라고 말한다. OTL
만들라면서요..
"내가 만들라고 했던건 이런게 아니라.. 어쩌구 저쩌구...주절주절..."
아니 그걸 이제와서 말씀하시면 어떡해요..

누가 잘못한걸까..
개발자도 기획자도 모두 잘못했다.

모든 소프트웨어 프로젝트는 항상 고객에게 기능을 제공하기 위한것이라는 공통된 목적이 있다.
고객은, 개발자가 자기 혼자 쓰려고 만들때는 자기 자신이 될 것이고, 사내 지원조직이나 시스템조직에게는 운영조직이나 다른 시스템조직 또는 서비스를 받는 유저가 고객이 될 것이고(전문용어로 내부고객이라고도 한다), 제조업체의 개발조직에게는 제품을 구입해 주는 소비자(이건 당연히 외부고객이다)가 고객일 것이다. 어떤 경우건 고객은 언제나 위대하시고 언제나 옳은 말씀만 하신다는걸 기억해야 한다.
고객이 "난 이렇걸 원해요"라고 말하는데, "그게 아니죠.. 당신은 이런걸 원하는 것입니다"라고 말할수 있는가? 과연 그게 맞다고 생각하는가? 무슨 근거로?

그래서 스펙화과정, 명세서 작성과정이 꼭 필요하다는 것이다.

XP(eXtreme Programming)이라는 방법론에서 말하길 고객을 개발과정에 참여시키라고 한다.
명세서를 작성하는 과정이 고객이 개발과정에 참여할 아주 좋은 단계이다.
우선,
"이 소프트웨어가 (또는 하드웨어라도 마찬가지..) 이러한 기능을 하며, 이 기능들을 위해서 사용자에게 이러한 인터페이스를 제공하고, 사용자에게 보이지 않는 곳에서 데이터들을 이렇게 조직하기 때문에 이러이러하게 응용한 기능들을 얼마든지 만들수 있다."
이런 "내용"이 명세서에 모두 들어가야 한다.
"물론 이 모든것을 구현하는데는 몇달의 시간이 소요되고, 그에 따른 비용이 얼마이므로, 이 제품의 가격은 얼마가 된다"
이런내용도 가급적 포함시키는게 좋다.

개발자들은 이런 과정을 싫어하는 경향이 있다.
늘 해왔듯이 에디터를 띄우고 코드를 적어 내려가고, 컴파일하고 실행시켜 보아서 고객이 말한 행동을 하는 소프트웨어가 되었는지 확인하는걸 개발의 왕도라고 생각한다. 하지만, 개발자는 실리콘으로 만들어진 것이 아니라 단백질로 만들어졌기 때문에 , 인간 사고 패턴의 한계를 벗어날 수는 없고, 망각이라는 한계로부터 자유로울 수 없다.
만일 당신의 두뇌는 실리콘으로 만들어져 있고 1.5V또는 3.3V의 전원을 공급해서 두뇌를 운용한다면 이따위 헛소리는 집어치라고 말해도 할말이 없다.(5V의 전원을 쓴다면 그따위 구닥다리 두뇌는 집어치우고 차라리 단백질을 택하라고 자신있게 말할 수 있다)
많은 개발자들이 고객은 기술에 대해 아는것이 아무것도 없는데 말도 통하지 않는 그런 사람들하고 어떻게 같이 스펙 작업을 하는가 라고 말할지도 모르겠다. 하지만 고객에게
"이 정보는 Windows 2003 server에 설치된 MS SQL에 저장되어 있으며, 3개의 테이블이 Foreign key로 엮여 있어 Data Integrity가 높게 유지될 수 있습니다. 그러나 Integrity에 대한 exception을 발생할 때의 handling을 위해서 wrapper를 만들 것입니다. 이렇게 하면 모든 컴포넌트의 Data I/O를 통제 할수 있습니다. Data의 I/O가 일어나면 blahblah Algorithm에서 증명된 방법으로 데이터를 가공합니다.
연산의 최소화를 위해 reference를 3개 사용하여 최적화를 수행할 수 있을 것입니다.
이렇게 가공된 데이터는 Bitmap object에 매핑되어 스크린 또는 프린터로 전송됩니다. 프린터로 전송될 때는 Postscript로 변환하기 위한 엔진이 사용됩니다. 어쩌구.."
이런 기술적인 얘기를 하라는게 아니다. 나도 이해 못하겠는 소리를 고객에게 하면 뭣하는가.
이런 현학적인(이 단어도 현학적이다;;) 명세서를 고개에게 들이밀면, 고객은 현란한 기술용어에 감탄하던지 겁을 먹고 개발자에게 "네.. 그렇게 만들어 주면 너무 훌륭하겠네요"라고 말해버린다.
솔직해져라. 이걸 노려왔지 않은가..

스펙명세서에는 크게 두가지 버전이 만들어지는게 정석인데, 하나는 Fuctional Specification(기능명세), 또 하나는 Technical Specification(기술명세)가 된다. 고객에게는 절대 기술명세를 보여줘서는 안되며 (기밀사항이 아니더라도 보여줘선 안된다.) 더욱이 함께 작성해 보자고 달려들어서도 안된다.명세는 쉽게 작성되어야 하는데, 기술명세는 개발자에게 아무리 쉽고 하찮은 내용일지라도 고객에게는 마법주문서와 같아보이게 마련이다.

절대로 명세서는 쉽게 작성해야 한다.
쉽게, 그리고 눈에 확 들어오도록, 가급적 재미있게(구어체를 섞어주는것도 좋다) 작성해야 한다. 명세서를 쉽고 재미있게 작성하지 않으면, 작성한 자신도 다시는 들여다 보지 않을 것이고, 본인이 지금 명세와 얼마나 다른 물건을 만들고 있는지 눈치채지 못하게 된다.
조엘 스폴스키는 "당신이 쉽고 재미있는 명세서를 작성하여 보여줬다고 당신을 얕잡아 보는 회사에서 일한다면, 다른 회사를 찾아보는게 좋을 것이다"라고 충고했다.

조엘, 당신은 대한민국을 모르는군요.. 대한민국은 스펙을 작성하는 사람을 시간을 축내는 사람, 머리가 나빠서 저렇게 정리하느라 시간을 다 써버리는 사람으로 취급한답니다. 젠장할 쉽고 재밌는 명세서를 보여줄 기회가 없기 때문에 우리 회사가 그런 명세서를 얕잡아 보는지 알수가 없다구요..

쉽고 재밌는 명세서(기능명세일 경우엔 특히나 더욱)를 작성할때는 적절히 예를 들어가면서 소프트웨어의 행동을 모두 보여주는 것이 좋다.
어떤 입력에 대해 어떻게 행동할 것인지를 고객과 함께 협의해 나가야 한다.
다이얼로그 박스에 붙어있는 버튼을 클릭하면 어떤 일이 일어날지를 협의해야 한다. 스펙이 구체화 되어 갈수록 다이얼로그박스에 로고를 넣을 것인지, 버튼을 가로로 배치할 것인지 세로로 배치할 것인지, 버튼의 크기는 얼마나 되어야 할지도 여러가지 안을 고객에게 보여주며 고르던지 더 좋은 제안을 하도록 유도해야 한다.

DVD대여 프로그램을 발주하는 DVD대여점 사장님은, 자기 점포의 고객 명단(주의! 우리 고객이 아니다, 우리 고객의 고객이다)을 가장 소중하게생각할 것이다. 사장님이 생각하는 가장 중요한 고객의 정보를 눈에 띄게 배치해서 맘에 드는지 물어봐야 한다. DVD대여점 고객의 취향을 대여 패턴으로 분석이 가능하도록 모든 DVD타이틀의 정보를 어떻게 입력하고 관리할지도 알려 주어야 한다. 사용법이 어렵다고 하면 쉽게 고쳐줘야 한다. 그런 정보를 관리하려 하는게 아니라고 하면 로직을 수정해 줘야 한다.

우리회사에 참 상대하기 힘든 DVD가게 사장님-_-이 있다.
"대여프로그램 만들어줄꺼죠?"
이 한마디 던져놓고 몇달동안 자기 일 하느라 관심도 없이 지내더니 요즘 부쩍 이래가지고 DVD대여를 어떻게 하냐고 땡깡이다. 그러면서 언제까지 되겠냐고 다짜고짜 들이댄다. 마치 내가 프로그램을 잘못 만들고 있으면서 태평하게 놀았기 때문에 자기가 지금 장사를 할수 없다는 식이다. 어쩌라구..
내배를 째던지..
우리 사장님한테 말해서 날 짜르던지..

에효.. 길어졌다.
내일 또 써야지..



덧. 써놓고 보니 내 사상은 확실히 "실용주의 프로그래머"와 "XP", "조엘의 블로그"의 영향을 심하게 받은거 같다;;;;

덧. 혹시 있을지도 모르는, 이 다음 과정이 궁금한 방문객을 위한 링크^^;;;

출처: http://luminance.kr/107

Trackback 0 Comment 2