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>>

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

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

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 CostBlank 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

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 AA220Base CA

TouchScreen

Dual CoreAA100

BB120YY001 ……

BB121

BB122

BB200BB130 BB210 BB220CA

TouchScreen

Dual CoreBB100

Base

C 지역 向 (C-I, C-II, C-III사업자)

CII100

ZZ001

CIII100

CII200

CIII200

TouchScreen

Dual Core

CI100 CII110

CII110

CIII110

C 지역의서로 다른사업자 向

CI200

……

OOO Protocol

BB110

4 / 18

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

Password 입력 컨트롤 ( *** )

6 / 18

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%의 소스 코드가 수정됨

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

…

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

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 방식

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.cFileManager_Interface FileManger_Interface.h, FileManger_Interface.cFileManagerLib FileManger_Util.h, FileManger_Util.c, FileMangerLib.h, …

Processor BrowseFolder.h, BrowseFolder.c, FileManager.c, FMTouchInputTextP.h, FMTouchInputTextP.c, InfoPopup.h, …

11 / 18

모듈 갂 호출 Cycle – 서로에게 요청, 모듈의 책임이 불분명

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

World Clock

DrawHvLine (void) DrawTimePane (void) DrawSubTitle (void)…

Restructuring WorldClock with MVC Pattern

SEOUL

indicator

SAT MAY 31 4:30 PM

ASIAZoom 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

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 (Technology Variations)

14 / 18

플랫폼담당

Common Mobile TV Platform

After

Protocol[2]

MTVDeveloper

Before

품질 문제 多비용↑커뮤니케이션 Overhead↑MTV

Developers

CBMS

CBMS BCAST MBMSmixed

단일 Protocol[1]일 때, SimpleBut…

특정 Protocol 에 집중모델개발대응

Common MTV Platform 구축 통한 Variation 관리다양한 방송 기술에 대해 효율적, 빠르게 대응

MTVDeveloper

Architect

Architect consulting 주요 내용• Variation Point들을 [2] 식별, 정리하고, expected 소프트웨어 구조를 제시

• 기존 구조 와 Expected 구조 갂 코드 상의 Gap을 분석하고, 소프트웨어 구조 개선 방법 가이드

• 현재짂행하는방향이맞는지?• 코드Directory 구조는어떻게?• 개선상황을어떻게체크?

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

외부 Solution을 개발 코드와 Mix하지 않고, Interface를 통해 경계 명확화

Abstract Factory

Netflix 코드의 DirectFB Graphic 사용에 대한 Interface 정의

BD300과 DTV 소프트웨어에서 각각 Porting 하지 않고, 한 벌의 Netflix 코드를 사용하도록

외부 Solution Evolution에 대해 Adaptation 작업 중복 방지

16 / 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 기능 구현과 병렧적으로 이루어질 수 있도록 함

Linear List English

Circular ListEspaña

Grid中國

…

Service UI engine

Service API

Presentation

Logic

CDMA WISE implementation

WISE 1.2implementation

Androidimplementation

OS/Platform

…

Presentation Variation

Logic Variation

Service Variation

17 / 18

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

Middleware Layer

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