반응형
<세미나 내용>


Feature Modeling Guideline


[배경 설명]

[RUP]-Rational Unified Process

User와 System간의 상호작용을, Usecase 로 표현하고, Usecase내에서 객체를 추출하는 방법을 예기하고 있다.

하나의 Usecase에서는 적어도 Inteface class와 Object, 그리고 일반 데이타에 해당하는 Entity Object 이 발생된다.(기본 공식과도 같다고함)
 -> 이말은 반대로 예기하면 Usecase를 작성해놓고 Interface class 와 object ,entity object 를 축축 할 수 없다면 잘못된 usecase라고 생각해야 할지도 모른다.즉, 제 검토가 필요하다.


[OOAD]
  -UML Notation
  -RUP(Usecase diagram)
 =>"재사용"
(class 모듈 단위)		 => Framework 
( Design pattern)		 (IT와는 잘맞고 적합하다.)
=> Business logic 단위로 재사용
(Component Based Development)



IT와 SOA 가 달라서 다른 디자인이 필요하게됨..
-> "제품군 단위로 제사용을하자" 

 - Product Line Engineering : Nokia /...

- 공통적으로 Architecture
S/W Platform : 제품군 + Scopping => Samsung 



S/W Platform   -  공통 가변 설계 (50%이상)  <- 제품군의 공통 가변 식별 <- Featrue Model 기법

Domain - 제품군으로 보면 된다.


[UML과 Feature model의 차이]
UML Usecase  --> Requirement Eng.(Analysis)   단위 Target Sys
       '사용자'

Feature
       사용자 관점 + Architect + 개발자  --> Domain Eng.(Analysis)     Product Line

       Feature 관점에서 나오는 모듈이나 요구사항들은 사용자 Level에서 이해가 가지 않는 부분들 많다.
       따라서, Feature model를 추진할때는 Domain Knowlage 를 가진 개발자들이 참여해야한다.


객체지향에서는 
Object type   <<Entity>> /   <<Boundry>> /   <<Control>> 
Feature model에서는
Feature type   <<Mandantoy>> /   <<Optional>> /   <<Alternative>> 



Feature Based Platform Develop Method
                        [방법론 가이드]
                    <강 교 철 교수 Postech >

Feature-Oriented Product Line Software Engineering
  Feature 기반 재사용 방법론


도메인 분석을 하고 어떻게 설계 구현을 해나가야 하나.



Feature Based Platform Develop Method
   (Samsung . Platform 설계 방법)

S/W Patform    -> Forward    - 완전히 새로 시작할때      
                     -> Re-Eng.    - 기존 s/w가 있는 상황에서 개발이 될때.
                    -- 방법의 차이는  Legacy 가 있냐 없냐의 차이가 있다.

--> 미완성 테그

Feature Identification & Analysis 
Behavior Analysis 
 Platfrom building Platofrm design & Evaluation
가변 설계 --> 
이걸로 안되기 때문에  -->		 QAW
Quality attribute 식별
Scenario 도출 및 상세화 
Architecture decision 도출
 플렛폼 아키텍쳐 설계
Static view /Dynamic view
 부품등록




아키텍쳐 : 시스템을 구성하는 기본단위인 컴포넌트와 이러한 컴포넌트를 어떻게 연결되어있는지 파악할수 있는 커넥터로 표현한것,
아키텍쳐 사상:               
<--

[Architecture modeling procedure]
Step 1. 아키텍쳐 구조 기본이 될 Layer선정
Step 2. Feature모델로부터 아키텍쳐 말단 구성 요소인 class 선정
Step 3. 동일 Layer하에서의 Shared data선정
Step 4. Later간 통신을 위해 Interface Mechanizm 구성
Step 5. 아키텍쳐 말단 구성 요소인 class간의 관계 설정
Step 6. Subsystem 수중의 관리를 위해 class를 package 화
    - 관련성 있는 .c 파일을 어떻게 관리할건가.
Step 7. 서비스 제공을 위한 Package Interface 설정
Step 8. 전체 시스템 구조를 Package들간의 관례로 구성


- detail
Step 2. Feature model로 부터 아키텍쳐 말단 구성 요소인 class 선정
   Feature model로 부터 optional/ Alternative Feature 들을 분리하여 독립 class로 선정.
       - 초기에 설계할때 가변부 파일들은 각각 분리 한다.

Static Architecture Design Principle


FORM ( Feature oriented reuse method)

'개발 Note > it 이야기' 카테고리의 다른 글

UI Modal 컨셉  (0) 2009.01.06
C++ 상에서 발생하는 name mangling 에 관한 내용  (17) 2009.01.04
Refactoring  (0) 2009.01.04
S60 platform architecture  (0) 2009.01.04
S60 Webkit & Nokia Browser architecture  (0) 2009.01.04
반응형
리펙토링에 대한 예기를 꺼내는데 먼저 Clear case같은 형상관리 툴에 대한 예기를 먼저 꺼내게 되었는데, 
S/W관리 및 유지보수를 위해 매우 중요한 일이기 때문이다, 더군다나 refactoring 시에도 매우 중요하게 적용되는 사항이기 때문에 먼저 예기하고자 한다.



[형상관리툴의 check-in]

형상관리시에 check in의 범위에 대해 다음과 같은 scope 에서 처리되어야 한다.

1 각각의 버젼은 단위 작업 내용이어야 한다.
    - 이전 코드와 이후 코드를 비교할때, 단위 작업이 아니라 이것 저것 수정한 경우에는 코드 비교시 많은 시간이 소비된다.
    - 2008.7.3일 퇴근 버젼!! <- 이런건 정말 난해한 버젼이 된다.
    - bug fix: ... 수정한 사항.   - refactoring: 코드 뭐 수정.... 이런식으로 버젼이 표시되어야 한다.

    이렇게 진행하는 이유는 코드 수정의 목적이 명확하고 ,수정 내역이 정확하여야 각 노드별 비교 분석이 가능해 지기 때문이다.
    우리가 흔히 하는 실수는 채크인 하는 목적과 실제 체크인 되는 내용이 다를때가 있다.
    코드 채크인 하는 이유는 bug fix인데,   실제 체크인 된내용은 맘에 안들던 함수 이름도 바뀌고, 변수도 수정하고, 다른 버그도 수정된 사항이 포함된다.
    그래서 형상관리상에 어떤 버그가 수정되었는지에 대한 기록이 없게 된다.

그러면 Refactoring 시 형상관리툴의 check-in은 왜 중요한 사항일까?
답은 간단하다.
Refactoring의 목적을 이해하면 왜 중요한 사항인지 파악하기가 쉽다.
Refactoring의 목적은 원래의 기능을 유지하면서 code를 여러가지 목적으로 수정하는 것을 의미한다.
        - 기존의 코드를 읽기 쉽도록( Readablity) 하여,
        - 유지 보수성(maintainability)을 높이는 것을 의미한다.
즉, 기존의 버그 수정이나 구조적 개선이 목적이 아니라 , 현제의 구조 및 기능에서 코드의 개선을 의미하는 것이다.
따라서, 이전 버전과 현재 수정된 버젼에서 무엇이 바뀌었는가? 이 코드 변경으로 인해 기능상의 변화가 있는가 등을 검토해보기 위해서는
이전 코드와 현재 코드를 비교하는 것은 꼭 필요하다.
이때문에 위와 같은 형상관리 툴의 check - in 정책은 꼭 필요한것이다.
또, 단순히 Refactoring을 위한 것 뿐만아니라 버그수정시에도 이와 같은 법칙은 적용된다고 봐야 한다.



[Refactoring]

목적
1.원래의 기능을 유지
2.이해하기 쉽고 수정하기 쉽도록 수정하는 것

리팩토링중 흔히 하는 실수중에 가장 조심해야 할것은,
   리팩토링 중에는 code 개선 작업만 해야하지 리팩토링중 발견된 버그를 수정해서는 안된다.
   *** 버그 수정으로 인한 코드 수정이 리팩토링이 올바르게 되었는지를 판단할수 없게 만들수도 있다.
          때로는 버그 수정으로 이로인해 비정상 동작이 나올수도 있는데, 이것이 리팩토링때문에 발생된 결과인지 
          버그 수정때문에 발생된 결과인지 판단하기 불분명해 지기 때문이다.
   리팩토링시 발견된 버그는 리팩토링 후에 따로 bug 리포팅후 fix 하는 시간을 따로 가져야 한다.
        

테스트 자동화 구현
원래 기능이 유지되는지 수정시 꼭 테스트 해야한다.
이를 위해 매번 수동 테스트를 하는 것보다 테스트 자동화를 구현하는 것이 편리하다.
기능 자동화 테스트가 없다고 한다면 Refactoring 결과를 매번 수동으로 확인해야 하고, 또 이러다보면 반드시 결과를 확인하지 않는 상황도 만들어지게 된다.



함수이름 변경
상당히 많은 내용을 내포하고 있다.

1.의미 있는 함수 이름으로 변경



2. OnceAndOnlyOnce
   : 함수 하나는 한가지 일만 하도록 작성 되어야 한다.
    동사 하나와 목적어 하나로 요약 할수 없다면.... 
    바람직하지 않은 구조--> 리팩토링 필요.

 바람직한 함수이름은   - 동사 하나 + 목적어 하나
 잘못된 이름의 예 ) MeasureRectAndDrawBorder....    -> MeasureRect 와 DrawBorder 를 나눌 필요가 있다.

The philosophy that information on how a piece of software operates - be it an algorithm, a set of constants, human-readable documentation, or something else - should exist in only one place. The practice of this is not always easy; in most languages (CommonLisp advocates claim that practicing OAOO is significantly easier for them), there are many types of situations where there is no obvious way to follow OnceAndOnlyOnce, or where following it requires more effort than simple duplication. The essence of it, however, is: Write everything once and only once - locate and fold together any duplication you find while adding the current feature. 

3. 함수이름이 적절하다면, 개발자입장에서는 그 함수에 대해 따로 문서가 필요 없다.
(문서화가 필요없다는 예기가 아니라, 개발자 입장에서 문서없이도 개발할 수 있을만한 함수라는 것이다. )

공유 자료구조에 대한 접근
전역변수, 공유자료에 대한 직접 접근을 피해야 한다.
 - 코드 중복 발생
 - 기타 예기치 못한 많은 문제들을 발생.
 - 절대 피해야함.
** standard lib에서 제공되는 기능이라면 이를 사용하라!!!
   이미 standard lib에서 테스트와 옵티마이즈가 끝난 함수들이기 때문에 믿을 수 있다.

전역변수->지역변수
 변수의 life cycle이 짧으면 짧을 수록 버그의 발생 요인을 줄일 수 있다.
 global>static>파일>함수>블럭 순으로 버그를 발생시킬 영역이 줄어든다.


expression 추출

반복된 문장 패턴이나 반복되는 expression 을 추출 대상으로 놓는다.

대표적인 예로, 영역 검사 루틴들이다.

if(( x>0&& x<maxw && y>0 && y<maxh) && pszText == NULL) ...
                    :
if(( x>0&& x<maxw && y>0 && y<maxh && winH<= MAX_HEIGHT)) ...
                    :
if(bEnter && ( x>0&& x<maxw && y>0 && y<maxh )) ...


이런식의 코드는 다음과 같이 수정
if( x>0&& x<maxw && y>0 && y<maxh)... -> if( PtInRc(x,y,&rcMax))



2개의 함수를 합칠때
**2개의 함수를 합치려 할때
    2개의 함수에서 공통으로 사용하는 변수는 서로 다른 이름으로 바꾼다.
    1. 사용되어지는 함수(put_stone) 에서 입력 parameter  x,y --> xx,yy 로 변경
    2. 만약 , xx,yy가 변경되지 않고 참조를 위해 읽기만 하는 경우라면 process_key 내에서 제거 가능하다.

Process_key()
{
   : 
  x = 10;
  y = 15;
  if( 어쩌고 저쩌고)
  {
    x = getUserX();
    y = getUserY();
  }
  put_stone(x,y);
}

bool  put_stone(int x,int y)
{
  :
  GameSysSetX(x);
  GameSysSetY(y);
 return 0;
}

    2개의 함수에서 공통으로 사용하는 변수는 서로 다른 이름으로 바꾼다.
    1. 사용되어지는 함수(put_stone) 에서 입력 parameter  x,y --> xx,yy 로 변경

Process_key()
{
   : 
  x = 10;
  y = 15;
  if( 어쩌고 저쩌고)
  {
    x = getUserX();
    y = getUserY();
  }
  put_stone(x,y);
}

bool  put_stone(int xx,int yy)
{
  :
  GameSysSetX(xx);  
  GameSysSetY(yy);
 return 0;
}
    2. 만약 , xx,yy가 변경되지 않고 참조를 위해 읽기만 하는 경우라면 process_key 내에서 제거 가능하다.
Process_key()
{
   : 
  x = 10;
  y = 15;
  if( 어쩌고 저쩌고)
  {
    x = getUserX();
    y = getUserY();
  }
    :
    GameSysSetX(xx);  
    GameSysSetY(yy);

}

    3. 알다 시피 xx,yy -> 해당 변수로 바꾸는 작업을 한다.



이와 같이 refactoring 전략은 보면 다들 머리속으로는 알고 있는 내용입니다.
딱 봐도 '당연한거 아냐' 라는 생각이 들 정도이죠.

허나 중요한것은 알고 있냐 가 아니라, 이렇게 하고 있는가 가 중요한것이겠죠.
처음부터 이러한 코딩을 해왔더라면, 따로 리팩토링이란걸 할 필요도 없는거죠.
다시 한번 강조하지만 리펙토링은 기존의 코드를 일기 쉽고 관리하기 편하도록 제 정리하는 작업이라고 
생각해야 합니다.

계층화

계층화는 리펙토링에서 사실 고난이도의 작업인데요. 리펙토링보다는 리스트럭쳐링에 가깝다고 보는 것이 옳습니다.( 리펙토링에도 리스트럭쳐링까지는 아니지만 계층화를 요구하는 경우가 있기 때문에 포함한 내용)

전체로직 계층
- 어플리케이션의 전체 로직의 흐름이 구현된 층
- 먼저 무엇을 하고, 그다음에 무엇을 하고...
-전체 작업의 흐름이 보인다.

단위작업 계층
- 단위 작업을 수행
- 세부 작업이 구현됨

유틸리티 계층
- 범용함수


Platform 화 할때:
  유틸리티 계층은 잘 만들어서 포함시키는 것이 맞고,
  단위작업 계층의 경우는 단번에 Pltform으로 이동은 힘들기 때문에 선행작업이 단위작업별로 잘 정리를 하는 것이 우선이다.
  그 후 단위 작업 계층이 많이 쌓이게 되면 그 후에 플렛폼으로 포함할수 있는 부분들만 포함시킨다.(물론 가공해서 platform에 맞게 정리함)

'개발 Note > it 이야기' 카테고리의 다른 글

UI Modal 컨셉  (0) 2009.01.06
C++ 상에서 발생하는 name mangling 에 관한 내용  (17) 2009.01.04
Feature modeling - 아직 정리되지 않은 주제.  (0) 2009.01.04
S60 platform architecture  (0) 2009.01.04
S60 Webkit & Nokia Browser architecture  (0) 2009.01.04
반응형

S60 platform architecture

The following figure illustrates the high level of architecture of the S60 platform. The platform is based on Symbian OS but also provides additional features:

Figure 1: S60 platform architecture


As shown in the above figure, S60 platform is based on the Symbian OS, which evolves all the time. As such, S60 platform has different editions. S60 platform has experienced 1st Edition, 2nd Edition, and the latest 3rd Edition. In each of the edition, it also introduces different feature packs, which incorporate some of the advanced features on each release. Symbian OS is based on open standard, which makes the development on Symbian/S60 open for the developers. The Development for the S60 platform is backward compatible although there was a break between the 2nd Edition and the 3rd Edition, which was introduced by the platform security and new compiler used in the platform.

The releases and their respective operating systems are:


  • S60 1st Edition — Symbian OS v6.1.
  • S60 2nd Edition — Symbian OS v7.0s.
    • S60 2nd Edition, Feature Pack 1 — Symbian OS v7.0s.
    • S60 2nd Edition, Feature Pack 2 — Symbian OS v8.0a.
    • S60 2nd Edition, Feature Pack 3 — Symbian OS v8.1a.
  • S60 3rd Edition — Symbian OS v9.1.
    • S60 3rd Edition, Feature Pack 1 — Symbian OS v9.2.
    • S60 3rd Edition, Feature Pack 2 — Symbian OS v9.3.

'개발 Note > it 이야기' 카테고리의 다른 글

UI Modal 컨셉  (0) 2009.01.06
C++ 상에서 발생하는 name mangling 에 관한 내용  (17) 2009.01.04
Feature modeling - 아직 정리되지 않은 주제.  (0) 2009.01.04
Refactoring  (0) 2009.01.04
S60 Webkit & Nokia Browser architecture  (0) 2009.01.04
반응형

Nokia forum에서 퍼온 자료입니다.

아키텍쳐를 공부하면서 현재 open되어있는 solution들은 아키텍쳐를 어떻게 잡아가고 있는지 참고하기 위해서 여기저기서 찾아보고 있는 중이랍니다.!!


S60WebKit & Nokia Browser Architecture

From Forum Nokia Wiki

Introduction

The Nokia Web Browser is built upon S60WebKit, a port of the open source WebKit project to the S60 platform.

WebKit contains the WebCore and JavaScriptCore components that Apple uses in its Safari browser. Based on KHTML and KJS from KDE's Konqueror open source project, this software has enabled Nokia to achieve improvements in Web site usability on smartphones through the re-use of a proven desktop rendering engine that has been developed and optimized by a large open source community over many years.

This browser enables smartphone users to browse full Web pages on a smartphone screen with features such as:

Preservation of the original page layout, presented just as the Web site designer intended; Easy navigation of Web pages through page miniatures, reducing the amount of scrolling; Pop-up blocking, enhanced start page, and simplified menus; Visual History, an easy-to-use back function, showing miniature views of previous pages; Text Search, which works as you type, taking you directly to the interesting part of the page; Dynamic HTML, supporting dynamic menus, rollovers, and scripted behavior such as AJAX applications; Extensive support of industry standards including W3C's HTML, XHTML 1.0, DOM, CSS and SVG-Tiny; other Web standards such as SSL and ECMAScript; and Netscape style plug-ins such as Flash Lite and audio. Figure 1 explains the architecture for the Nokia Web Browser.


Figure 1: S60 Browser Architecture

Documentation and source for the WebKit project are available at WebKit .

For Information about KDE's Konqueror please visit KDE's Konqueror.

Building S60Webkit

For instructions building S60Webkit, see Building S60Webkit .

'개발 Note > it 이야기' 카테고리의 다른 글

UI Modal 컨셉  (0) 2009.01.06
C++ 상에서 발생하는 name mangling 에 관한 내용  (17) 2009.01.04
Feature modeling - 아직 정리되지 않은 주제.  (0) 2009.01.04
Refactoring  (0) 2009.01.04
S60 platform architecture  (0) 2009.01.04

+ Recent posts

티스토리툴바