객체 지향 모델링은 기능이 아닌 객체가 중심이 되며 "누가 어떤 일을 할 것인가?"가 핵심 객체를 도출하고 각각의 역할을 정의해 나가는 것에 초점을 맞추는 것.

객체지향 프로그래밍(Object-Oriented Programming, OOP)이란?

컴퓨터 프로그램을 설계하는 기법 중 하나로, 컴퓨터 프로그램을 현실 세계의 대상과 그 기능을 객체화하여 표현하는 것

객체지향의 주요 개념

① 객체(Object)

• 실제로 존재하는 것. 클래스에 정의된 내용대로 메모리에 생성된 것

② 클래스(Class)

• 하나 이상의 유사한 객체들을 묶어 공통된 특성을 표현한 것
• 객체를 정의 해놓은 것. 객체의 설계도, 틀

③ 패키지(Package)

• 클래스를 묶어두는 물리적인 단위. 클래스들의 집합

④ 메시지(Message)

• 객체에게 어떤 행위를 하도록 지시하는 명령

⑤ 추상화

• 공통 성질을 추출하여 수퍼클래스로 구성한다.
• 객체 중심의 안정된 모델을 구축 가능 하며 현실 세계를 자연스럽게 표현.

⑥ 상속(Inheritance)

• 부모 클래스가 가지고 있는 필드와 메소드를 자식 클래스에서 그대로 물려받아 사용하는 것.

⑦ 캡슐화(Encapsulation)

• 필요한 속성(Attribute)와 행위(Method)를 하나로 묶고 그중 일부를 외부에서 사용하지 못하도록 은닉하는 것
• 캡슐화는 객체가 가지고 있는 프로퍼티에 대한 직접적인 접근을 막고, 별도의 메서드를 통해 접근하거나 수정하도록 하는 것이며 이때 접근지정자를 사용.

⑧ 다형성

• 상속받은 여러 개의 하위 객체들이 다른 형태의 특성을 갖는 객체로 이용될 수 있는 성질.

⑨ 집단화 | is part of

• 클래스 간의 구조적인 집약 관계
• "클래스 A는 클래스 B와 클래스 C로 구성된다"

⑩ 일반화 | is a

• 클래스들 간의 개념적인 포함 관계
• "자식 클래스 A는 부모 클래스 B의 일종이다."

객체지향 언어의 4가지 특성

추상화, 상속, 캡슐화, 다형성

객체지향 설계 원칙(SOLID)

① 단일 책임 원칙(SRP, Single Responsibility Principle)

• 모든 클래스는 하나의 책임만 가지며, 클래스는 그 책임을 완전히 캡슐화해야 함
  

② 개방 폐쇄의 원칙(OCP, Open-Closed Principle)

• 소프트웨어 개체(클래스, 모듈, 함수 등등)는 확장에 대해 열려 있어야 하고, 수정에 대해서는 닫혀 있어야 한다
  

③ 리스코프 교체(치환)의 원칙(LSP, Liskov Substitution Principle) 컴퓨터 프로그램에서 자료형 S가 자료형 T의 하위형이라면 필요한 프로그램의 속성(정확성, 수행하는 업무 등)의 변경 없이 자료형 T의 객체를 자료형 S의 객체로 교체(치환)할 수 있어야 한다는 원칙

④ 인터페이스 분리 원칙(ISP, Interface Segregation Principle)

• 클라이언트가 자신이 이용하지 않는 메서드에 의존하지 않아야 한다는 원칙
  

⑤ 의존성 역전 원칙(DIP, Dependency Inversion Principle) -의존 관계를 맺을 때 변화하기 쉬운 것 보다 변화하기 어려운 것에 의존하라는 원칙을 의미한다.

객체지향 분석 기법

• 소프트웨어를 개발하기 위한 비즈니스(업무)를 객체와 속성, 클래스와 멤버, 전체와 부분 등으로 나누어서 분석해 내는 기법

객체지향 분석 기법의 종류

1) 럼바우 분석기법

• 동적 모델링 기법이 사용될 수 있다.
• 데이터와 행위를 하나로 묶어 객체를 정의내리고 추상화시키는 작업이라 할 수 있다.
• 코드 재사용에 의한 프로그램 생산성 향상 및 요구에 따른 시스템의 쉬운 변경이 가능하다.
  

*① 객체(Object) 모델링 | 객체 다이어그램 *

• 정보모델링, 시스템에서 요구되는 객체를 찾아내어 속성과 연산 식별 및 객체들 간의 관계를 규정, 객체 다이어그램으로 표시
  

② 동적(Dynamic) 모델링 | 상태 다이어그램

• 상태도(상태 다이어그램)을 이용하여 시스템의 행위를 기술
  

③ 기능(Functional) 모델링 | 자료흐름도

• 자료 흐름도를 이용하여 다수의 프로세스들 간의 자료 흐름을 중심으로 처리 과정 표현
  

2) Coad-Yourdon 방법**

• 객체, 동적, 기능 모델로 나누어 수행하는 방법이다.
• 미시적 개발 프로세스와 거시적 개발 프로세스를 모두 사용하는 방법이다.
• Use-Case를 강조하여 사용하는 방법이다.
• E-R 다이어그램을 사용하여 객체의 행위를 모델링
• 객체 식별, 구조 식별
  

3) Booch 방법

• 미시적, 거시적 개발 프로세스를 모두 사용하는 분석방법.
• 클래스와 객체들을 분석 및 식별하고 클래스의 속성과 연산을 정의
  

4) Jacobson 방법

• Use Case를 사용하여 분석
• 사용자, 외부 시스템, 다른 요소들이 시스템과 상호 작용 하는 방법을 기술
  

5) Wirfs-Brock

• 분석과 설계간 구분이 없으며, 고객 명세서를 평가하여 설계 작업까지 연속적으로 수행
  

요구사항(要求事項, 영어: Requirement)이란 시스템 개발 분야에서 어떤 과제를 수행하기 위하여 필요한 조건이나 능력을 말한다. 시스템 개발 및 운영 시 발주자가 특정 과제를 수행하는데 필요한 조건과 능력을 체계적으로 정리하여 요구사항 번호를 붙여서 제안요청서를 작성하고, 제안자가 해당 요구사항에 맞춰 제안서를 작성한다.

요구 사항 분석 과정

• 분석 결과의 문서화를 통해 향후 유지보수에 유용하게 활용할 수 있다.
• 자료흐름도, 자료 사전 등이 효과적으로 이용될 수 있다.
• 보다 구체적인 명세를 위해 소단위 명세서(Mini-Spec)가 활용될 수 있다.
  

요구사항의 검증

• 실제로 고객이 원하는 바를 정의했는지를 확인하는 과정
• 시스템을 개발하거나, 시스템이 운영 중일 경우에 발견되면 방대한 재작업 비용이 발생되기 때문에 사전에 검증하는 작업이 필요
• 시스템을 변경하여 요구사항 문제를 수정하는 비용은 설계 및 코딩오류에 비하여 비용이 많이 소요됨.
  

인터페이스 요구사항 검토(검증) 방법

• 동료 검토(Peer Review) : 요구사항 명세서 작성자가 요구사항 명세서를 설명하고 이해관계자들이 설명을 들으면서 결함을 발견
• 워크스루(Walk Through, CASE 도구) : 검토 회의 전, 명세서를 미리 배포하여 사전검토 후에 짧은 검토 회의를 통해 결함 발견
• 인스펙션(Inspection) : 요구사항 명세서 작성자를 제외한 다른 검토 전문가들이 명세서를 확인하면서 결함을 발견
  

요구사항의 체크리스트 (Requirements Checklist)

1) 유효성(Validity) : 고객의 필요를 충족하는 기능을 제공하는가? 2) 일관성(Consistency): 충돌하는 요구사항이 존재하는가?(모순되는 제약조건이 없는가?) 3) 완결성(Completeness): 고객이 요구한 모든 기능이 포함하는가? 4) 현실성(Realism): 예산과 기술적으로로 실행 가능한가? 5) 검증 가능성(Verifiability): 개발한 뒤 요구사항들을 검증할 수 있는가?

요구사항의 구분

1) 기능적 요구사항

• 시스템이 수행해야 하는 행위들을 구체화 한 것
• 시스템에서 제공해야 할 기능을 정의한 것
• 입력기능, 출력기능, 데이터베이스 기능, 통신 기능 등

2) 비기능적 요구사항

• 시스템이 가져야 하는 기능 이외의 요구사항
• 시스템의 전체적인 품질이나 고려해야 하는 제약사항 등
• 사용 용이성, 효율성, 신뢰성, 이식성, 유연성, 확장성 등
• 성능적인 면: 응답 속도, 자원 사용량 등
• 보안 측면: 침입 대응, 침입 탐지, 사용자 인증, 권한 부여 등
  

요구사항 개발 프로세스

도출(Elicitation) → 분석(Analysis) → 명세(Specification) → 확인(Validation)

요구사항 분석 시에 필요한 기술

• 청취와 인터뷰 질문 기술
• 분석과 중재기술
• 관찰 및 모델 작성 기술
  

요구사항 분석이 어려운 이유

• 개발자와 사용자 간의 지식이나 표현의 차이가 커서 상호 이해가 쉽지 않다.
• 사용자의 요구사항이 모호하고 불명확하다.
• 사용자의 요구는 예외가 많아 열거와 구조화가 어렵다
• 소프트웨어 개발 과정 중에 요구사항이 계속 변할 수 있다.
  

요구사항 모델링에 사용되는 도구

• Data Flow Diagram
• UML Diagram
• E-R Diagram
• 애자일(Agile) 방법
• 유스케이스 다이어그램(Use Case Diagram)
• 시퀀스 다이어그램(Sequence Diagram)
  

요구사항 관리 도구의 목적

• 요구사항 변경으로 인한 비용 편익 분석
• 요구사항 변경의 추적
• 요구사항 변경에 따른 영향 평가
  

요구 사항 명세기법

1-1) 정형 명세법의 종류

• 수학적 기반/모델링 기반
• Z, VDM, Petri-Net(모형기반)
• CSP, CCS, LOTOS(대수적방법)
  

1-2) 정형 명세법의 특징

• 시스템 요구특성이 정확하고 명세가 간결하다. 명세와 구현이 일치.
• 수학적 기호, 정형화된 표기법으로 작성
• 정확하고 간결하게 표현할 수 있지만 표기법이 어려워 사용자가 이해하기 어렵다.
• 일관성이 있다.
  

2-1) 비정형명세법의 종류

• 상태, 기능, 객체 중심 명세법
• FSM(Finite state machine)
• Decision Table, ER모델링
• State chart(SADT)
• UseCase : 사용자기반모델링
  

2-2) 비정형명세법의 특징

• 명세 작성이 간편하고 의사전달 방법이 다양하다.
• 일반 명사, 동사 등의 자연어를 기반으로 작성한다.
• 이해가 쉽다.
• 일관성이 떨어진다.
  

• 안드로이드(Android)는 리눅스 커널을 기반으로 구글에서 만든 모바일 운영체제(OS)입니다.
• 2008년 안드로이드 1.0을 첫 출시한 이후, 현 시점 모바일 OS에서 IOS와 경쟁하고 있는 OS입니다.

안드로이드의 특징

• 공개 운영체제인 리눅스를 기반으로 합니다.
• 또한, 안드로이드의 운영채제의 주요부분과 라이브러리 구글이 만든 앱 등의 코드는 대부분 공개되어 있습니다.
• IOS와는 다르게 안드로이드 OS는 다양한 디바이스를 타겟으로 합니다. 따라서, 안드로이드 개발자는 다양한 안드로이드 디바이스에 대한 대응을 고려해야 합니다.
• 안드로이드 플랫폼에서는 모든 응용 프로그램이 평등하다는 사상을 바탕으로, 모바일 디바이스에 설치된 앱과 개발자가 만든 앱은 동일한 API를 사용합니다.

안드로이드 운영체제의 구조

출처 : https://developer.android.com/guide/platform?hl=ko

안드로이드 운영체제는 위와 같은 아키텍처로 구성되어 있습니다. 이러한 구조 중에서 특별히 더 중요하게 알아두어야 할 부분은 다음의 세 가지입니다.

① 리눅스 커널 ② 하드웨어 추상화 레이어(HAL, Hardware Abstract Layer) ③ 안드로이드 런타임(ART, Android Runtime)

안드로이드 소스코드의 컴파일 과정

• 안드로이드는 컴파일 과정을 거쳐 최종적으로 DEX파일로 컴파일 됩니다.
• 안드로이드 소스코드는 자바 또는 코틀린으로 작성되는데, 작성된 소스코드는 각 언어별 컴파일로를 통해 바이트 코드인 .class 파일로 컴파일됩니다.
• 그후 .class파일은 .dex 확장자를 가지는 DEX 파일로 다시 한번 컴파일 됩니다.

그래서 dex는 무엇일까?

• dex는 구글에서 모바일 디바이스에서 사용하기 위해 만들었습니다.
• dex는, Dalvik Executable의 약자이고, Dan Bornstein이 작성한 오픈 소스 소프트웨어입니다.
• Dalvik이라는 이름은 아이슬란드의 작은 어촌마을인 Dalvík 에서 기원하였다고 합니다.

JVM vs DVM

안드로이드에 .dex가 사용되는 이유를 이해하려면, JVM과 DVM에대한 이해가 필요합니다.

먼저, JVM은 클래스가 필요할 때마다 동적으로 .class 파일을 읽습니다. 이 때 JVM은 컴퓨터의 메모리를 사용하게 되고 스택 기반으로 opcode(작업코드) 를 읽어서 사용합니다. 반면, DVM은 .dex라는 파일에 모든 클래스 파일들을 변환하여 저장합니다. 즉 하나의 파일에 모든 소스가 있는 셈입니다. 그리고 이러한 dex파일로부터 DVM은 opcode(작업코드) 를 읽어서 사용합니다.

정리하자면, JVM은 필요할 때마다 클래스 파일 중에서 골라 쓰는 셈이고, dex는 하나의 파일에서 관리한다는 것입니다.

그런데, 스택 기반의 가상머신은 컴퓨터의 메모리에서 스택으로 프로그램을 관리하는 반면, 레지스터 기반의 가상머신은 컴퓨터 CPU에 직접 접근하기 때문에 속도 측면에서 더 빠르나, CPU의 한정된 메모리를 사용하기 때문에 메모리 용량이 작다 는 단점이 있습니다.

메모리 용량 측면에서는 스택기반의 가상머신인 JVM이 유리하지만, 속도 측면에서는 레지스터 기반의 DVM이 유리한 것입니다.

왜 구글은 DVM을 채택했을까?

지금의 모바일 및 컴퓨터 하드웨어 기술 수준을 생각하면, 굳이 레지스터말고 자바 기반의 JVM을 사용해도 좋았을 것 같은데, 이 이유에 대해서 아직 안드로이드 스튜디오나 구글의 공식 입장을 찾아보진 못했습니다.

그러나, 제 스스로 그 이유를 추론해보자면 안드로이드 OS가 탄생했던 당시의 시대적 배경을 생각하면, 오히려 JVM 보다 DVM을 선택하는 것이 더 합리적이었다고 생각됩니다.

왜냐하면, 초기 모바일 디바이스는 메모리 용량이 그렇게 크지도 않았고, 지금도 안드로이드 앱은 수많은 앱들이 하나의 디바이스에서 빠르게 상호작용하고 동작해야하는 점을 고려해보면, 클래스 로더로 .class 파일을 읽어 들여서 동작하는 JVM보다 컴파일 과정을 한번 더 거치더라도 DVM을 채택하면 빠른 속도도 취하고 안드로이드 앱의 라이프 사이클에 따른 빠른 자원의 관리도 유리한 것으로 보여 JVM보다 DVM이 더 합리적이었을 것 같다는 생각이 들었습니다.

물론, 구글은 아마 이보다 더 많은 이유를 포함하여 OS를 설계하고 개발했겠지만, 제 스스로 찾아 보면서 생각해봤을 때는 이러한 이유로 구글이 JVM이 아닌 DVM을 선택했던 것이 더 합리적이라고 판단했을 것 같습니다.

dex를 사용함으로 인해서 발생한 문제점

이러한 안드로이드의 아키텍처에 따라서 모든 클래스 파일들은 최종적으로 .dex 로 컴파일이 됩니다. 그래서, 안드로이드 개발에서 자주 사용하는 jar 파일들은 어떻게 DVM에서 동작하게 되는지 의문이 생길 수 있습니다. 이는 jar 파일도 dx(Dexer) 를 통해 .dex파일로 컴파일되기 때문에 가능합니다. 그렇기에 dx(Dexer)는 안드로이드의 SDK(Software Develop Kit) 의 표준 구성 요소가 되었습니다.

하지만, dex는 앞서 설명한 구조적 한계 때문에 다음과 같은 이슈가 있습니다.

1. ANR(애플리케이션 응답 없음)의 발생, 즉 너무 큰 .dex 파일을 읽어들임으로 인해 애플리케이션이 일시적으로 중단되는 것입니다.

2. multidex 기반 애플리케이션은 Android 4.0(API 레벨 14) 미만의 시스템에서는 정상적으로 작동하지 않을 수 있습니다.

참고하면 좋을 사이트 : https://www.boldare.com/blog/differences-between-class-and-dex-files-in-java-android/

안드로이드 개발 도구

• 대부분의 안드로이드 앱은 Java로 만든 API를 통해서 개발을 하게 됩니다.
• 그러나, 안드로이드 앱은 C나 C++로 개발된 네이티브 라이브러리도 사용할 수 있는데, 이를 안드로이드 NDK(Native Development Kit) 라고 합니다.
• 자바로 만든 라이브러리들은 자바 API 프레임워크 라고 부릅니다.

안드로이드 API LEVELs

안드로이드와 컴포넌트

안드로이드 앱 개발의 핵심은 컴포넌트입니다. 안드로이드에서 동작하는 프로그램을 보통 APP 또는 어플리케이션이라고 칭합니다. 이러한 안드로이드 앱은 컴포넌트로 구성되어 있는데, 안드로이드 앱은 다음의 4가지 컴포넌트로 구성되어 있습니다.

1. 액티비티

• 안드로이드의 화면 표시(뷰 바인딩 등)를 전적으로 담당하는 컴포넌트입니다.
• 앱 화면을 리소스 파일과 바인딩하여 사용자에게 상호작용 가능한 인터페이스를 구성하는 역할을 합니다. 액티비티 컴포넌트는 안드로이드 시스템에서 자동으로 생명주기를 관리해 줍니다.
• 따라서 개발자는 별도로 생명주기를 관리하지 않아도 안드로이드 시스템에서 기본적으로 생명주기를 관리해줍니다.

2. 서비스

• 화면이 없는 것이 가장 큰 특징인 안드로이드 컴포넌트입니다.
• 안드로이드에서 앱이 구동중이 아니더라도 백그라운드에서 특정 작업을 수행하고자 할 때 사용할 수 있습니다.
• 서비스는 서비스의 라이프 사이클을 가지며 액티비티처럼 서비스만의 라이프 사이클을 가집니다.
• 네트워크 통신과 같이 시간이 오래 소요되는 작업은 서비스 컴포넌트에서 관리하는 것이 바람직합니다.
• 서비스 컴포넌트의 생명주기는 대부분의 경우 안드로이드 시스템에서 생성(Create)과 파괴(Destroy)를 관리해줍니다.

3. 브로드캐스트 리시버

• 안드로이드 OS를 탑재한 모바일 디바이스에서 일어나는 여러가지 하드웨어 이벤트들을 감지할 수 있는 컴포넌트입니다.
• 브로드캐스트 리시버에서 감지하는 이벤트들은 안드로이드 앱 내의 액티비티에서 사용자와 상호작용을 통해 발생하는 이벤트와는 구분되는 개념이며, 주로 전원꺼짐 화면 켜짐과 같이 모바일 디바이스의 하드웨어에서 감지하는 이벤트에 대해서 감지하고 대응할 수 있도록 해줍니다.

4. 콘텐츠 프로바이더

• 안드로이드 OS의 파일 시스템 관리자 격의 역할을 수행하는 컴포넌트 입니다.
• 데이터베이스, 파일 또는 네트워크 등의 다양한 데이터를 관리하고 다른 앱과 데이터 공유를 가능하게 합니다.
• 데이터의 CRUD(Create, Read, Update, Delete) 작업을 제공하고, 안드로이드 시스템 및 다른 앱에서 데이터에 접근할 수 있도록 합니다.

안드로이드에서는 모든 자바 클래스가 컴포넌트인 것은 아닙니다. 안드로이드에서 말하는 컴포넌트들은 위에 설명한 네 가지 컴포넌트 클래스를 상속받는 자바 클래스를 가르키는 말입니다. 또한, 안드로이드 앱은 컴포넌트 뿐만 아니라 일반 클래스도 사용되며 앱마다 필요한 기능을 구현하고 서비스하기 위해 개발자가 직접 만들거나 도입하여 사용하기도 합니다.

안드로이드와 리소스(Resource) 관리

안드로이드 앱 내에서 사용되는 정적 자원들은 리소스를 기반으로 개발합니다. 여기서 리소스란 앱의 레이아웃, 색상 값 등 앱 실행중에 변하지 않는 값들을 의미합니다. 안드이드에서는 이러한 값들을 .xml 파일로 관리합니다.

안드로이드 앱에서 정적인 값들을 담은 xml은 앱 내에서 런타임 시 파싱하여 사용하게 됩니다. 그런데, 이러한 자원들은 .java나 .kt와 같은 자바나 코틀린 클래스로도 관리할 수도 있습니다. 그러나 보통 안드로이드 개발을 하는 데에는 보통 XML로 값을 관리하는 편이며, 안드로이드 스튜디오에서도 이러한 방식을 권장합니다.

만약 리소스를 클래스 파일로 관리하게 되면, 컴파일 시간에 값이 결정되므로, 실행 시간에 추가적인 리소스를 사용하지 않습니다. 반면에, XML 파일은 런타임에 파싱되어야 하므로, 실행 시간에 약간의 오버헤드가 발생 할 수 있습니다.

하지만, 이러한 성능 차이는 무시할 정도로 작아서 실제로는 거의 영향을 미치지 않습니다. 따라서, 안드로이드에서 색상 값과 같은 리소스를 관리하는 것은 개발자의 개발 스타일과 개발 환경에 따라 선택할 수 있는 부분이긴 합니다.

그럼에도 일반적으로는 회사에서는 UX/UI 디자이너와 같이 개발자가 아닌 동료와도 협업하고 소통하기 위해서라도 클래스 파일로 작성하는 것보다 xml 파일로 작성해서 관리하는 것이 더 효율적인 편입니다.

그리고 개발하다 보면 고객의 요청에 따라 수정사항이 발생해도 파일 한 두개의 값만 바꾸어주면 다른 앱들을 수정하지 않아도 관리할 수 있다는 장점이 있어서 안드로이드에서 리소스의 관리는 XML 파일로 별도로 관리하는 것이 권장됩니다.