#action Blog 블로그 더하기 ##Blog {{{#!blog hyacinth 2010-03-29T03:07:18 8장 Requirement => 요구사항 use-case => 시스템 Modeling => 설계도 1. Structured analysis e.g) 순서도 2. OO analysis 객체->interaction a=f(b,c); { d=f2(a); e=f3(d,c,b); * DFD(Data Flow Diagram) http://pages.cpsc.ucalgary.ca/~jadalow/seng613/Group/report/image012.gif http://pages.cpsc.ucalgary.ca/~jadalow/seng613/Group/report/SASD_2002.html 간단하게 시스템을 도시화 큰 기능과 필요한 데이터 어떤 데이터를 처리할 것인지 정의 Behavioral Modeling * State Diagram -user interaction -user event 이벤트 처리 DFD는 이벤트를 처리하기 힘든데 State Diagram은 이벤트 중심 Identify event(<-> DFD(identify data)) * Sequence Diagram event, 흐름, 객체 외부 시스템과의 interaction을 표현 시스템 전체적으로 interal한 메시지 교환을 설계 가능 시스템 설계하는데 보편화된 방법. 많이 쓰임. 가장 시스템을 이해하기 쉽다. -- 210.94.213.72 [[Date(2010-03-29T02:33:07)]] -''''''--- 설계 Design and Quality 디자인의 퀄러티 - 모든 요구사항을 만족시킨다. 설계도를 보고 구현할 수 있어야 한다. - 읽기 편해야 한다. - 개발자뿐만 아니라 누구나 알아 볼 수 있어야 한다. - ... (*pdf) Quality Guidelines - ... - ... - ... - ... (*pdf) Patterns > Design Pattern Template - ... (*pdf) Separation of Concerns feature가 있으면 각자 가능하면 분리하는 것이 좋다. 는 개념. Modularity 가능하면 모듈화 하는 것이 좋다. 무조건 자르는 것이 아닌 특정 feature와 1:1로 맵핑 Modularity:Trade-offs "적절한" 모듈화가 소프트웨어의 cost가 가장 낮아진다. Information Hiding 사용자 인터페이스만 제공. 아래 사항은 은닉 - 알고리즘 - 자료 구조 - 디테일한 외부 인터페이스 - ... Why Information Hiding? (*pdf) Stepwise Refinement Functional Independence 물론 설계 단계에선 중요한 내용이다. -Cohesion 결합성. 가능한 모듈 하나가 기능 하나만. -Coupling 의존성에 대해. Aspects Refactoring (*그 뒤 pdf 그림들은 UML 도시화) -- 210.94.213.72 [[Date(2010-03-29T02:59:20)]] -''''''--- 8장 숙제- 수요일 이전까지 공지 제출 손으로(?) 조교에게 제출 -- 210.94.213.72 [[Date(2010-03-29T03:00:18)]] }}} [[HTML(
)]] http://hyacinth.byus.net/img/flower.jpg [[HTML(
)]] {{{#!blog hyacinth 2010-03-22T01:26:24 Understanding Requirements 요구사항의 단계 * Inception * Elicitation * Elaboration * Negotiation * Specfication * Validation * Requirements management ==== Inception ==== Identify stakeholder 누가 이 소프트웨어에 관여하고 누가 참여하고 개발할 것인가. 사용자 입장에서, 개발자 입장에서 파악. 관리. 비용 관리 등. 각자의 관여자, 참여자간의 이해관계. Recognize multiple points of view 각 사용자들이 원하는 바 파악. Work toward collaboration 기획자, 개발자 등들을 어떻게 모아서 일을 할 것인가. ==== Eliciting Requerements ==== 이 단계에서 구체화 Collaborative Requirement Gathering 각 단계의 구체적인 requrements를 구체적으로 수집. 문제가 무엇인가. 솔루션 제시. QFD 우선순위를 정하는데 쓰는 도구. 직관적이 아닌 Formal하게. Building the Analysis Model Scenario-based elements Class-based elements Use-Cases 시나리오 단계에서 많이 사용. 기본적으로 actor를 만듬. Use-Case Diagram 작대기 사람이 formal한 actor (-_-;) 말풍선 등으로 entity들을 표현. Class Diagram || ''' Sensor ''' || || name/id || || type || || location || || area || || characteristics || || identify() || || enable() || State Diagram class diagram이 구체적으로 어떠한 값들을 가질 것인지, state를 정의. Negotiating Requrements 진행된 부분을 프로젝트에 관여된 사람들에게 보여주고 부족한 부분은 없는지 수정할 부분은 없는지. Validating Requirements Is each requirement consistent with the overall objectives? Have all requirements been specified at the proper level? Is the requirement really necessary or does it represent an add-on feature that may not be essential? Is each requirement unambiguous? 요구사항이 전체적인 프로젝트 목적과 맞는지 '' 쓸만할 정도로 디테일하게 되었는지. 모호하거나 쓸모없는 부분은 없는지. 구현 가능한지, 테스트가 가능한지 전체적으로. || Requirements -> Scenario -> Use-case -> Class Diagram -> State Diagram -> Negotiating Requrements -> Validating Requirements || ==== Requirements Modeling ==== Requirements Analysis Domain Analysis Use-case Diagram Activity Diagram 필요한 액션 step-by-step 순서도 Data Modeling ERD Class-Based Modeling CRC Modeling 오퍼레이션을 하는데 필요한 클래스가 무엇인지 명세 || Use-case Diagram -> Activity Diagram(Swimlane Diagram) -> Data Modeling(ERD) -> Class-Based Modeling -> CRC Modeling || }}} [[HTML(
)]] http://hyacinth.byus.net/img/flower.jpg [[HTML(
)]] {{{#!blog hyacinth 2010-03-22T01:21:24 1 주제 : 알람 시스템 Single Alarm System 간단한 가정 상황을 두고 구현. 4개의 앱. 터미널. 서버. 컨트롤러(장비). 센서. MFC 모두. 4개의 윈도우가 있다고 하고. 센서에 사용자가 값을 입력을 할 수 있게 하면 입력을 받아서. 서버에 값을 던져 주면, 서버는 터미널에. 터미널에선 센서의 값을 디스플레이. 사용자는 다시 액션을 취할 수 있다. 컨트롤러에 액션이 반영. 예) Light를 켜라. Window를 open, close 등. 4개가 각자 독립된 앱. 네트웍으로 연결. TCP/IP. 1 팀이 누구. 도구. 프로그래밍 언어. 간략하게. 2 시스템요구사항. 기능. 요구 사항. }}} [[HTML(
)]] http://hyacinth.byus.net/img/flower.jpg [[HTML(
)]]