2009년 품질관리 심포지움 발표자료

1. 2009. 10. 14
박찬짂
LG전자 CTO Software 센터
1. Software Evolution
2. Structural Bad Smells
3. Architectural Practices in Evolutionary Software Development
4. Architect’s Roles
Introduction of Architectural Practices in
Embedded Software Development
<< 제13회 소프트웨어 품질관리 심포지움, SQMS 2009>>

2. Challenges for Embedded Software
 Complexity, Growing features
 Software Moore’s Law (size)
 Processor 및 Memory 성능 개선 및 가격 하락 => H/W보다는 S/W로 기능 구현
 Diversity, Segmented market
 복수 제품 모델들의 동시 출시 (Global market)
 Segmented된 시장에서 단일 모델로 대응 어려움
 Lead time, 제품화 시갂의 단축
1 / 18

3. Software Evolution
 Law of program evolution, Lehman’s Law
 프로그램이 변경되지 않으면 도태되고, 이러
한 개선 변경을 통해 더욱 복잡해짂다
 Law of continuing change: A system that is being
used undergoes continuing change or degrades
in effectiveness.
 Law of increasing complexity: A computer
program that is changed, becomes less and less
structured. The changes increase the entropy
and complexity of the program
 Architecture degeneration by modification
 침식과 표류(Architectural Erosion,
Architectural Drift, D. Perry)
 Software Aging
Program, like people, get old. …. A sign that the
Software Engineering profession has matured will be
that we lose our preoccupation with the first release
and focus on the long term health of our products.
D. L. Parnas, Software Aging, 16th ICSE, 1994
2 / 18

4. Evolution phases
 Blank Phase, 새로욲 소프트웨어 개발 시기
 Integration
 여러 사이트 혹은 Segment들의 요구사항 반영 위해 새로욲 기능, 외부 기능들을 통합
 Market에서 성공하면 여러 Variation Model들이 만들어짐
 Country Adaptation, Luxury vs. Cheap Model, Chipset Change for Cost Reduction, …
 Magic
 Maintenance의 어려움을 겪으며, 소프트웨어가 복잡해져서 새로욲 기능 추가한 새 모델
의 출시가 어려욲 시기
Value produced
Cumulative Cost
Blank
phase
Integration Magic
3-4 모델이 성공적으로
개발되고 안정화되는
시기
소프트웨어 변경
비용이 급증 (새
로욲 변경 대응
능력이 떨어짐)
J. klein, “How Does the Architect’s Role Change as the Software Ages?,” Proc. Of the 5th Working IEEE/IFIP
Conf. on Software Architecture (WICS’05), 20053 / 18

5. Evolutionary Software Development
 이전 코드에 기반한 개발 작업
 Copy & Modify
 국가 및 사업자 요구사항 대응, 칩셋 변경, 새로운 기술의 적용(e.g. flash, widget, touch) 등
 Major change와 Minor change
 Base model, derived model
A 向 (A사업자)
B 向 (B사업자)
AA110XX001 ……
AA111
AA112
AA200AA120 AA210 AA220
Base CA
Touch
Screen
Dual Core
AA100
BB120YY001 ……
BB121
BB122
BB200BB130 BB210 BB220
CA
Touch
Screen
Dual Core
BB100
Base
C 지역 向 (C-I, C-II, C-III사업자)
CII100
ZZ001
CIII100
CII200
CIII200
Touch
Screen
Dual Core
CI100 CII110
CII110
CIII110
C 지역의
서로 다른
사업자 向
CI200
……
OOO Protocol
BB110
4 / 18

6. Bad smells – Code Clones
 Copied code
 버그 수정 및 기능 개선 시 동일 작업이 중복 요구됨, 작업 누락 시 품질 문제
 Refactoring에 소극적 (코드 삭제/수정의 Side Effect 발생 우려)
5669개 Application
Code 분석 (CCFinder)
* 플랫폼 구조적 제약으로 인
한 중복 (e.g. 모든 Win32 응용
은 Event 처리 Loop를 가짐)
* 평균적으로 Duplicate code
와 Unused code는 전체 코드
의 10% 가량 (경험적)
5 / 18

7.  Password 입력 컨트롤 ( *** )
6 / 18

8. Bad smells - Scattered changes
 Model A를 Base Model로 하는 Derived Model B, C의 코드 변경량 분석
 Application Source 분석
Model A
Model B
Model C
LCD Size 변경
Key pad  Touch pad
Bar  Slide
Evolutionary Software Development에서는 변경을 Localize할 수 있는 프로그램의 구조가 중요
- Display Size, 기능의 추가/다양성 (e.g. TV, BT), UI Customization, 표준 Protocol…
7 / 18
12.4
%
1.4%
86.2
%
7.7%
52.8%
39.5%
added
modified
unchanged
Model A  B
SLOC File
40.9%
3.6%
55.5%
26.3%
57.2%
16.5%
added
modified
unchanged
Model A  C
SLOC File
Minor 변경 임에도 불구하고, 전체 파일 수의 반 이상이 수정
많은 파일들을 살펴봐야 하므로, 작업 Effort가 커짐
(Delocalized Changes)
Major 변경의 경우, 80% 이상의 파일에서 추가/변경이 일어나
며 45%의 소스 코드가 수정됨

9.  Model A  B(Bar type에서 Slide type), Application 디렉터리 별 코드 변경률
 14% 코드 라인 변경 (SLOC)에 61%의 파일들이 변경 (# of files)
Changed LOC Ratio
Changed File Ratio
추가된 Application[1]
변경률이 높은 Application[2]
Changed Ratio = (Added + Deleted + 2*Modified)/ (Base Code + Derived Code)
8 / 18
…

10. Bad smells – Gaps bet’n conceptual structure and physical structure
 개념적 아키텍처와 실제 구현 아키텍처 갂의 차이
 Linux Architecture
Conceptual Architecture Physical Architecture
Bowman et al., Linux as a Case Study: Its Extracted Software Architecture, ICSE’99
9 / 18

11. Platform Architecture
 Platform Strategy (Platform Architecture)
 Layered & Composable 플랫폼의 구축을 통해 플랫폼 Infrastructure를 구성하고, 시장 요
구 및 기술 성숙도에 따라 Strategic 플랫폼을 점짂적으로 구축
Product Focused Layered Composable Strategic
………… Device Driver Layer
Middleware Layer
Application Layer
……
Device Driver Layer
Application Layer
Middleware Layer
Platform Core
…… 부품 부품부품
Device Driver Layer
Application Framework
Middleware Layer
Platform Core
…… 부품 부품부품
* Product Focused : 시장에 처음 짂입하거나, 차별적이고 Unique한 소프트웨어를 개발 시, 기술 Solution이 대중화되어 자사
기술 확보 가치가 적을 때 (Outsourcing), 예상하지 못한 기술,시장의 급격한 변화에 빨리 대처할 필요가 있을 때
* Layered 플랫폼 : 시장의 변화가 심하지 않고 기능의 추가 요구가 적을 때, 제품 모델 갂 차별성이 적을 때, Device 의존성을
관리할 필요가 있을 때
* Composable 플랫폼, Strategic 플랫폼 : 다양한 요구에 따라 시장이 Segmented되어 있을 때, 다수의 모델을 동시에 출시할
필요가 있을 때, 기술 Convergence 형태가 다양할 때
10 / 18
아키텍처 분할: Evolution 시 변경 정도, Evolution 방식

12. Reverse Architecting Existing Code
 Construct and Analyze As-is Architecture
 Then, Propose To-be Architecture, Restructure Code, Check Conformance of Code
 Code Architecture for FileManager Application
 Flat architecture: 하나의 디렉터리 내에 38개 구현 파일
 Grouping based on file name: 6 Module
Name Files
AdaptDRM AdaptDRM.h,AdaptDRM.c (DRM 관련)
ExternalAPI ExternalAPI.h,ExternalAPI.c
FileManager_Interface FileManger_Interface.h,FileManger_Interface.c
FileManagerLib FileManger_Util.h,FileManger_Util.c,FileMangerLib.h,…
Processor BrowseFolder.h,BrowseFolder.c,FileManager.c,
FMTouchInputTextP.h,FMTouchInputTextP.c,InfoPopup.h, …
11 / 18
모듈 갂 호출 Cycle – 서로에게 요청, 모듈의 책임이 불분명

13.  Restructuring to Layered Architecture & MVC decomposition
 Cycle 제거, Layered 구조로 변경: 모듈 갂 상호 호출 의존이 없도록
 Model – View – Controller로 구분: 별도 파일을 정의하여 함수 이동
 Model(재사용 가능한 Core Operation) , View (Draw 로직), Controller(이벤트 처리)
Processors: 화면 관렦 구현,
External: DRM, MMS와 같은 외부 구현과의 통싞
Controller: UI에 message가 전달되었을 때 처리
View: Call_Popup(popup box 관렦), View(drawing 관렦), …
Model: File operation
12 / 18

14.  World Clock
DrawHvLine (void)
DrawTimePane(void)
DrawSubTitle (void)
…
Restructuring WorldClock with MVC Pattern
SEOUL
indicator
SAT MAY 31 4:30 PM
ASIA
Zoom in Back
World clock
OnDraw()
View
Controller
Model
void OnKeyDown(KEY Key) {
stNvRec * nvRec = NULL;
nvRec = SysHeap_Alloc(sizeof(…));
switch (Key) {
case SOFT1_K:
ChangeCity((int)-1);
…
OnDraw();
LOCAL void ChangeCity(int count) {
if ((PrimaryCityIdx >= MAX_CITY_NUM - 1) …
PrimaryCityIdx = 0;
else if(PrimaryCityIdx <= 0 && count < 0)
PrimaryCityIdx = MAX_CITY_NUM - 1;
….
선택된 City 정보 관리
Key와 같은 Event에 대한 처리
Draw로직
ChangeCity (int)
SetCurrentHomeID(int)
GetCurrentHomeID(void)
…
OnInit (void)
OnExit (void)
OnAwake (void)
OnKeyDown (KEY Key)
….
 UI와 이벤트 처리 로직의 변경을 Localize
 새로욲 GUI Framework로 대체 (Flash, Widget, …)
 Model 코드의 재사용
13 / 18

15.  Common Mobile TV Platform 구축 지원 (고정부-변동부의 구분)
[1] CBMS, BCAST, MBMS 등 다양한 방송 Protocol이 존재. 지역/사업자 마다 상이한 Protocol 채택
[2] Protocol 외, 사업자, Security, AV codec, Chipset, OS 등에 의해 MTV SW 구현이 서로 상이함  Variation point
Separating Protocol-Specific Part (TechnologyVariations)
14 / 18
플랫폼
담당
Common Mobile TV
Platform
After
Protocol[2]
MTV
Developer
Before
품질 문제 多
비용 ↑
커뮤니케이션 Overhead↑MTV
Developers
CBMS
CBMS BCAST MBMS
mixed
단일 Protocol[1]일 때,
 Simple
But…
특정Protocol 에 집중
모델개발대응
Common MTV Platform 구축 통한 Variation 관리
 다양한 방송 기술에 대해 효율적, 빠르게 대응
MTV
Developer
Architect
Architect consulting 주요 내용
• Variation Point들을 [2] 식별, 정리하고, expected 소프
트웨어 구조를 제시
• 기존 구조 와 Expected 구조 갂 코드 상의 Gap을 분석
하고, 소프트웨어 구조 개선 방법 가이드
• 현재짂행하는방향이맞는지?
• 코드Directory구조는어떻게?
• 개선상황을어떻게체크?

16. Porting Netflix with Abstract Factory
 Netflix
 Netflix is the largest online DVD rental service, offering flat rate rental-by-mail and online
streaming to customers in the United States. It has over 55 million discs and ship 1.6
million a day, on average
 “BD 300” uses DirectFB for graphic engine. But, DTV Lab uses NanoX for graphic
engine.
15 / 18

17.  외부 Solution을 개발 코드와 Mix하지 않고, Interface를 통해 경계 명확화
 Abstract Factory
 Netflix 코드의 DirectFB Graphic 사용에 대한 Interface 정의
 BD300과 DTV 소프트웨어에서 각각 Porting 하지 않고, 한 벌의 Netflix 코드를 사용하도록
 외부 Solution Evolution에 대해 Adaptation 작업 중복 방지
16 / 18

18. UI Application Architecture
 Challenges for UI Application Development
 Various Platform: Android, LiMo, Window Mobile, Feature phone platform
 New UI Scenario, UI Technology(S/W, H/W)
 Application Mashup (SNS, Tagging, …)
 Logic API 관리를 통해 화면 요소 변경 시 구현 코드 변경 최소화하고, Service API의
도입을 통해 UI Part 변경이 Phone 기능 구현과 병렧적으로 이루어질 수 있도록 함
LinearList
English
Circular List
España
Grid
中國
…
Service UIengine
Service API
Presentation
Logic
CDMAWISE
implementation
WISE1.2
implementation
Android
implementation
OS/Platform
…
PresentationVariation
Logic Variation
ServiceVariation
17 / 18

19. Architect’s Roles in Evolutionary Software Development
 Tech. expert vs. software architect
 DB Architect, Linux Architect, CDMA Architect?
 Software Architect
 Architect는 구조를 통해 소프트웨어 시스템을 분석하고
Decision을 할 수 있는 사람
 Roles of Software Architect in Evolutionary Software
Dev.
 각 기술 분야별 아키텍트(Expert)와 협업하여, 개발 효율
성 제고 및 생산성 향상을 위해 소프트웨어 구조 짂단 및
개선 방향을 제시
 In Addition, Architecting for the first release of product
(Reusability, Performance, Security, …)
……
Product focused
Device Driver Layer
MiddlewareLayer
Application Layer
Platform
…… 부품 부품부품
Strategic
Device Driver Layer
Middleware Layer
Application Layer
……
Layered Composable
Device Driver Layer
Middleware Layer
Application Layer
부품
Platform 부품
부품……
Technical Expert &
Domain Expert
Software Architect
• S/W 구조 분석/개선 방향 제시
• S/W 개선 전략 수립 지원
• S/W 구조 추출/짂단 솔루션 개발
“Mr. Beck, what is software architecture?”
asked a participant at an OOPSLA
workshop in Vancouver in the fall of 1992.
“Software architecture?” replied Kent, now
famous for being the father of XP, “well, it is
what software architects do.” (Chuckles in
the audience.)
“So then, what is an architect?”
“Hum, „software architect‟ it‟s a new
pompous title that programmers demand to
have on their business cards to justify their
sumptuous emoluments.”
18 / 18