必ず覚えること
検索系
Ctrl + Shift + R -> リソース検索（名称で探す場合、1つのファイル、*利用可能）
Ctrl + H -> 検索（名称、内容で探す場合、複数のファイル、*利用可能）
Ctrl + F -> ファイル内検索（置き換えも含む）
クラス名をの上にカーソルがある場合、
F3 -> クラスの定義、インターフェースの場合、インターフェースの定義
Ctrl + メソッドの上にマウスオーバー ->
インターフェースの場合、定義、実装のメニューが現れ、実装の方を選ぶ。
クラス名をの上にカーソルがある場合、
Ctrl + Shift + G -> ワークスペース内の参照
インポート系
Ctrl + Shift + O -> 不要のimportの整理
Ctrl + Shift + M -> インポートの追加
コメント系
Ctrl + Shift + / -> ブロック コメントの追加
Ctrl + Shift + \ -> ブロック コメントの除去
Ctrl + / -> コメントの切り替え
Ctrl + Shift + J -> Javadoc コメントを追加
その他
Ctrl + Shift + F -> フォーマット
2017년 8월 23일 수요일
스프링(Spring) 프레임워크 기본 개념 강좌 (1) - 스프링 이해하기 출처: http://ooz.co.kr/170 [이러쿵저러쿵]
http://ooz.co.kr/170
JAVA개발자를 위한 스프링 기본 개념 이해를 돕기 위한 강좌를 진행할 예정입니다.
스프링을 처음 접하시거나 개념에 대해 이해가 좀 더 필요하신 분들을 위해 작성한 것으로 스프링을 이미 잘 다루시거나 전문적으로 하시는 분들에게는 크게 유용하지 않을 수 있습니다. 또한 실무보다는 개념 위주로 작성된 강좌입니다.
저 또한 스프링 환경에서 개발 경력이 긴 것도 아니고, 스프링에 대해 모든 것을 완벽하게 이해하고, 사용하는 것은 아닙니다.
많이 부족하지만 그래도 제가 JAVA 개발 초기에 스프링에 대해 배우면서 정리하여 PPT로 작성한 내용을 스프링에 처음 입문하시는 분들께 도움이 되었으면 하는 바람으로 포스팅하였습니다.
참고로 본 강좌는 PPT로 작성하였던 강좌를 거의 그대로 작성한 것으로 자세한 설명이 많이 부족할 수도 있습니다.^^
혹시 내용에 대해 이해가 잘 안되시면 댓글로 질문 해주시면 아는 범위 내에서 답변드리도록 하겠습니다.
그리고 잘못된 내용이 있어도 바로 잡아주시면 감사하겠습니다.
그리고 추가적으로 스프링 개념 정리하면서 제 나름대로 정리한 부분이 대부분이나, 점선 박스로 된 내용은 스프링 강좌 이해를 돕기 위해 별도로 수집한 내용으로 다른 출처의 자료를 가져와 인용한 경우가 많습니다. 당시 자료를 만들면서 출처에 대한 부분을 따로 정리하지 않았는데, 뒤 늦게 출처를 확인하여, 코멘트를 단 경우도 많으나, 확인이 불가했던 출처도 있었습니다. 혹시 원 출처를 알려주시면 해당 원 출처에 대해 링크를 걸고, 저작물에 대해 허용이 되었는지 확인하고, 수정하도록 하겠습니다.
-------------------------------------------------------------------------------------------------------------------------------
1. 스프링의 이해
1.1) 스프링 정의
- 간단히 스프링이라 지칭하지만 정확하게는 스프링 프레임워크 (Spring Framework) 라고 하는 것이 정확한 표현.'
* 자바(JAVA) 플랫폼을 위한 오픈소스(Open Source) 애플리케이션 프레임워크(Framework)
* 자바 엔터프라이즈 개발을 편하게 해주는 오픈 소스 경량급 애플리케이션 프레임워크
* 자바 개발을 위한 프레임워크로 종속 객체를 생성해주고, 조립해주는 도구
* 자바로 된 프레임워크로 자바SE로 된 자바 객체(POJO)를 자바EE에 의존적이지 않게 연결해주는 역할.
- POJO 란 Plain Old Java Object 의 약자로 특별한 뜻을 담고 있는 용어는 아니며, 단순히 평범한 자바빈즈(Javabeans) 객체를 의미함.
- 참고 -
JAVA : JAVA 개발 언어
Open Source : 소프트웨어 혹은 하드웨어의 제작자의 권리를 지키면서 원시 코드를 누구나 열람할 수 있도록 한 소프트웨어 혹은 오픈 소스 라이선스에 준하는 모든 통칭을 일컫는다. (소스가 공개되어 여러 개발자가 플랫폼을 함께 개발, 구축, 보완해 나가는 시스템. )
Framework : 개발할 때 설계 기본이 되는 뼈대나 구조 / 환경 (문제 영역을 해결한 재사용, 확장 가능한 라이브러리.)
POJO : http://ko.wikipedia.org/wiki/Plain_Old_Java_Object
1.2) 스프링 특징
* 크기와 부하의 측면에서 경량.
* 제어 역행(IoC)이라는 기술을 통해 애플리케이션의 느슨한 결합을 도모.
* 관점지향(AOP) 프로그래밍을 위한 풍부한 지원을 함.
* 애플리케이션 객체의 생명 주기와 설정을 포함하고 관리한다는 점에서 일종의 컨테이너(Container)라고 할 수 있음.
* 간단한 컴포넌트로 복잡한 애플리케이션을 구성하고 설정할 수 있음.
- 스프링의 특징을 좀 더 상세히 말하자면 -
1) 경량 컨테이너로서 자바 객체를 직접 관리.
각각의 객체 생성, 소멸과 같은 라이프 사이클을 관리하며 스프링으로부터 필요한 객체를 얻어올 수 있다.
2) 스프링은 POJO(Plain Old Java Object) 방식의 프레임워크.
일반적인 J2EE 프레임워크에 비해 구현을 위해 특정한 인터페이스를 구현하거나 상속을 받을 필요가 없어 기존에 존재하는 라이브러리
등을 지원하기에 용이하고 객체가 가볍다.
3) 스프링은 제어 반전(IoC : Inversion of Control)을 지원.
컨트롤의 제어권이 사용자가 아니라 프레임워크에 있어서 필요에 따라 스프링에서 사용자의 코드를 호출한다.
4) 스프링은 의존성 주입(DI : Dependency Injection)을 지원
각각의 계층이나 서비스들 간에 의존성이 존재할 경우 프레임워크가 서로 연결시켜준다.
5) 스프링은 관점 지향 프로그래밍(AOP : Aspect-Oriented Programming)을 지원
따라서 트랜잭션이나 로깅, 보안과 같이 여러 모듈에서 공통적으로 사용하는 기능의 경우 해당 기능을 분리하여 관리할 수 있다.
6) 스프링은 영속성과 관련된 다양한 서비스를 지원
iBatis나 Hibernate 등 이미 완성도가 높은 데이터베이스 처리 라이브러리와 연결할 수 있는 인터페이스를 제공한다.
7) 스프링은 확장성이 높음.
스프링 프레임워크에 통합하기 위해 간단하게 기존 라이브러리를 감싸는 정도로 스프링에서 사용이 가능하기 때문에 수많은 라이브러리
가 이미 스프링에서 지원되고 있고 스프링에서 사용되는 라이브러리를 별도로 분리하기도 용이하다.
출처 : http://ko.wikipedia.org/wiki/%EC%8A%A4%ED%94%84%EB%A7%81_%ED%94%84%EB%A0%88%EC%9E%84%EC%9B%8C%ED%81%AC
- 또다른 특징 -
* 동적(Dynamic) 웹 사이트 개발을 위한 프레임워크
* 대한민국 전자정부 표준 프레임워크의 기반 기술
1.3) 스프링 역사
* Rod Johnson 이 2002년 출판한 자신의 저서 Expert One-on-One J2EE Design and Development에 선보인 코드가 시초.
* 이 프레임워크는 2003년 6월 최초 아파치 2.0 라이선스로 공개.
* 2004년 3월에 1.0 버전이 릴리즈 되고, 2011년 12월에 현재 최신 버전인 3.1 버전이 공개됨.
참고) 로드 존슨이 자신의 JAVA 개발 경험과 노하우를 기반으로 출판한 책에 샘플 프레임워크를 만들어서 저서에 실었는데, 이것이 차후 스프링이란 자바 표준 프레임워크로 발전하게 됨.
출처: http://ooz.co.kr/170 [이러쿵저러쿵]
JAVA개발자를 위한 스프링 기본 개념 이해를 돕기 위한 강좌를 진행할 예정입니다.
스프링을 처음 접하시거나 개념에 대해 이해가 좀 더 필요하신 분들을 위해 작성한 것으로 스프링을 이미 잘 다루시거나 전문적으로 하시는 분들에게는 크게 유용하지 않을 수 있습니다. 또한 실무보다는 개념 위주로 작성된 강좌입니다.
저 또한 스프링 환경에서 개발 경력이 긴 것도 아니고, 스프링에 대해 모든 것을 완벽하게 이해하고, 사용하는 것은 아닙니다.
많이 부족하지만 그래도 제가 JAVA 개발 초기에 스프링에 대해 배우면서 정리하여 PPT로 작성한 내용을 스프링에 처음 입문하시는 분들께 도움이 되었으면 하는 바람으로 포스팅하였습니다.
참고로 본 강좌는 PPT로 작성하였던 강좌를 거의 그대로 작성한 것으로 자세한 설명이 많이 부족할 수도 있습니다.^^
혹시 내용에 대해 이해가 잘 안되시면 댓글로 질문 해주시면 아는 범위 내에서 답변드리도록 하겠습니다.
그리고 잘못된 내용이 있어도 바로 잡아주시면 감사하겠습니다.
그리고 추가적으로 스프링 개념 정리하면서 제 나름대로 정리한 부분이 대부분이나, 점선 박스로 된 내용은 스프링 강좌 이해를 돕기 위해 별도로 수집한 내용으로 다른 출처의 자료를 가져와 인용한 경우가 많습니다. 당시 자료를 만들면서 출처에 대한 부분을 따로 정리하지 않았는데, 뒤 늦게 출처를 확인하여, 코멘트를 단 경우도 많으나, 확인이 불가했던 출처도 있었습니다. 혹시 원 출처를 알려주시면 해당 원 출처에 대해 링크를 걸고, 저작물에 대해 허용이 되었는지 확인하고, 수정하도록 하겠습니다.
-------------------------------------------------------------------------------------------------------------------------------
1. 스프링의 이해
1.1) 스프링 정의
- 간단히 스프링이라 지칭하지만 정확하게는 스프링 프레임워크 (Spring Framework) 라고 하는 것이 정확한 표현.'
* 자바(JAVA) 플랫폼을 위한 오픈소스(Open Source) 애플리케이션 프레임워크(Framework)
* 자바 엔터프라이즈 개발을 편하게 해주는 오픈 소스 경량급 애플리케이션 프레임워크
* 자바 개발을 위한 프레임워크로 종속 객체를 생성해주고, 조립해주는 도구
* 자바로 된 프레임워크로 자바SE로 된 자바 객체(POJO)를 자바EE에 의존적이지 않게 연결해주는 역할.
- POJO 란 Plain Old Java Object 의 약자로 특별한 뜻을 담고 있는 용어는 아니며, 단순히 평범한 자바빈즈(Javabeans) 객체를 의미함.
- 참고 -
JAVA : JAVA 개발 언어
Open Source : 소프트웨어 혹은 하드웨어의 제작자의 권리를 지키면서 원시 코드를 누구나 열람할 수 있도록 한 소프트웨어 혹은 오픈 소스 라이선스에 준하는 모든 통칭을 일컫는다. (소스가 공개되어 여러 개발자가 플랫폼을 함께 개발, 구축, 보완해 나가는 시스템. )
Framework : 개발할 때 설계 기본이 되는 뼈대나 구조 / 환경 (문제 영역을 해결한 재사용, 확장 가능한 라이브러리.)
POJO : http://ko.wikipedia.org/wiki/Plain_Old_Java_Object
1.2) 스프링 특징
* 크기와 부하의 측면에서 경량.
* 제어 역행(IoC)이라는 기술을 통해 애플리케이션의 느슨한 결합을 도모.
* 관점지향(AOP) 프로그래밍을 위한 풍부한 지원을 함.
* 애플리케이션 객체의 생명 주기와 설정을 포함하고 관리한다는 점에서 일종의 컨테이너(Container)라고 할 수 있음.
* 간단한 컴포넌트로 복잡한 애플리케이션을 구성하고 설정할 수 있음.
- 스프링의 특징을 좀 더 상세히 말하자면 -
1) 경량 컨테이너로서 자바 객체를 직접 관리.
각각의 객체 생성, 소멸과 같은 라이프 사이클을 관리하며 스프링으로부터 필요한 객체를 얻어올 수 있다.
2) 스프링은 POJO(Plain Old Java Object) 방식의 프레임워크.
일반적인 J2EE 프레임워크에 비해 구현을 위해 특정한 인터페이스를 구현하거나 상속을 받을 필요가 없어 기존에 존재하는 라이브러리
등을 지원하기에 용이하고 객체가 가볍다.
3) 스프링은 제어 반전(IoC : Inversion of Control)을 지원.
컨트롤의 제어권이 사용자가 아니라 프레임워크에 있어서 필요에 따라 스프링에서 사용자의 코드를 호출한다.
4) 스프링은 의존성 주입(DI : Dependency Injection)을 지원
각각의 계층이나 서비스들 간에 의존성이 존재할 경우 프레임워크가 서로 연결시켜준다.
5) 스프링은 관점 지향 프로그래밍(AOP : Aspect-Oriented Programming)을 지원
따라서 트랜잭션이나 로깅, 보안과 같이 여러 모듈에서 공통적으로 사용하는 기능의 경우 해당 기능을 분리하여 관리할 수 있다.
6) 스프링은 영속성과 관련된 다양한 서비스를 지원
iBatis나 Hibernate 등 이미 완성도가 높은 데이터베이스 처리 라이브러리와 연결할 수 있는 인터페이스를 제공한다.
7) 스프링은 확장성이 높음.
스프링 프레임워크에 통합하기 위해 간단하게 기존 라이브러리를 감싸는 정도로 스프링에서 사용이 가능하기 때문에 수많은 라이브러리
가 이미 스프링에서 지원되고 있고 스프링에서 사용되는 라이브러리를 별도로 분리하기도 용이하다.
출처 : http://ko.wikipedia.org/wiki/%EC%8A%A4%ED%94%84%EB%A7%81_%ED%94%84%EB%A0%88%EC%9E%84%EC%9B%8C%ED%81%AC
- 또다른 특징 -
* 동적(Dynamic) 웹 사이트 개발을 위한 프레임워크
* 대한민국 전자정부 표준 프레임워크의 기반 기술
1.3) 스프링 역사
* Rod Johnson 이 2002년 출판한 자신의 저서 Expert One-on-One J2EE Design and Development에 선보인 코드가 시초.
* 이 프레임워크는 2003년 6월 최초 아파치 2.0 라이선스로 공개.
* 2004년 3월에 1.0 버전이 릴리즈 되고, 2011년 12월에 현재 최신 버전인 3.1 버전이 공개됨.
참고) 로드 존슨이 자신의 JAVA 개발 경험과 노하우를 기반으로 출판한 책에 샘플 프레임워크를 만들어서 저서에 실었는데, 이것이 차후 스프링이란 자바 표준 프레임워크로 발전하게 됨.
출처: http://ooz.co.kr/170 [이러쿵저러쿵]
2017년 8월 22일 화요일
c#은 쉽지 않다..
C#만 10년 정도 개발해온 개발자로서 C#으로 DB조회같은 쉬운코딩만 하셔서 그런거 아닐까 하네요 ㅋ
단순crud는 우리회사 6개월차 신입들도 쉽다고 합니다
단순 문법적인 랭귀지 스펙측면이 아닌 C#으로 구현기술적 난이도는 C# 개발 10년차가 넘어가도 어렵습니다. 물론 자바로해도 어렵겠죠. 그게 실력이고 경력입니다.
간단한예로 IEnumerable<T>와 List<T>와 ICollection의 성능상의 차이점을 인지하고 코딩하신다던가
enumerable foreach와 for의 차이점을 알고 코딩한다던가
ToList, ToArray 등의 성능이슈에 대한 적절한 해결방법을 인지하신다던가.
EntityFramework + EnterpriseLibrary + Dapper로 ORM Framework 를 개발한다던가.
Parallel로 병렬처리를 Locking, CrossThread현상 없이 Threadsafe하게 Invoke처리 하신다던가
Reflection으로 모델의 property을 데이터소스로 부터 자동화처리 하신다던가
MVC의 PartialView를 직접 코드로 렌더링해서 Json 처리한다던가
DI를 직접 구현해 보신다던가
CustomControl(usercontrol 아님)로 그리드나 챠트 컨드롤을 GDI+로 개발한다던가
하는 형태의 개발해보시면 절대 쉽다고 하지못하실거에요.
test
Contextual Classes
Contextual classes can be used to color table rows or table cells. The classes that can be used are: .active, .success, .info, .warning, and .danger.
| Firstname | Lastname | |
|---|---|---|
| Default | Defaultson | def@somemail.com |
| Success | Doe | john@example.com |
| Danger | Moe | mary@example.com |
| Info | Dooley | july@example.com |
| Warning | Refs | bo@example.com |
| Active | Activeson | act@example.com |
Spring Web MVC, @Controller 어노테이션 정리
Spring Web MVC, @Controller 어노테이션 정리
클래스 레벨
Spring Web MVC의 @Controller 클래스에서 클래스 레벨에 명시 가능한 어노테이션은 아래와 같다.
@ResponseBody: 모든 메써드의 리턴 오브젝트를 적절한 형태로 변환 후 HTTP 응답 메시지의 바디에 담아 반환한다.
(오브젝트에서 바디로의 실제 변환은 HttpMessageConverter 인터페이스의 각 구현 클래스들이 수행한다.
예를 들면 String 리턴 타입은 StringHttpMessageConverter가 변환을 담당한다.)
클래스 레벨에 명시하면 View로의 반환을 완전히 배제하기 때문에 REST API 구현시 적합하다.
@RestController: @Controller에 위에 설명한 @ResponseBody를 추가한 효과를 가진다.
REST API 구현을 염두한 축약형 어노테이션이다.
@RequestMapping: 응답을 수행할 HTTP 요청을 명시할 수 있다.
path (String, String[]): 요청 URI를 명시한다. 배열을 통한 복수개의 요청 URI를 지정할 수 있다.
클래스 레벨에 명시한 값은 모든 메써드 레벨에 명시한 path 값 앞에 붙어 접두어 역할을 한다.
@RequestMapping("/v1/players")
@PropertySource: 프라퍼티 소스를 명시할 수 있다. 필드 레벨에서 @Value 등을 통해 클래스 레벨에서 명시한 프라퍼티 소스의 값을 주입할 수 있다.
// ROOT CLASSPATH(/src/main/java/resources)에 위치한 some.properties를 프라퍼티 소스로 명시한다.
@PropertySource("classpath:/some.properties")
클래스 필드 레벨
필드 레벨에 명시 가능한 어노테이션은 아래와 같다.
@Autowired: 적합한 이름의 스프링 빈을 자동으로 주입한다. 명백하게 1개의 스프링 빈만 존재할 경우 사용한다.
@Resource: 지정한 이름의 스프링 빈을 주입한다. 같은 타입의 스프링 빈이 2개 이상 존재할 경우 사용한다.
name (String): 주입할 스프링 빈의 이름이다.
@Value: 시스템 환경 변수, Java 환경 변수, Spring 환경 변수, 프라퍼티 리소스 상수 등의 값을 주입한다.
메써드 레벨
@RequestMapping: 메써드가 어떤 HTTP 요청을 처리할 것인가를 작성한다. 구체적인 작성 예는 아래와 같다.
@RequestMapping(
/**
* HTTP URI가 "/users"인 것만 처리한다. 만약 앞서 클래스 레벨에서 "/v1"이 명시되었다면 "/v1/users"를 처리하게 된다.
*/
path = "/users",
/**
* HTTP 요청 메써드가 "POST"인 것만 처리한다.
*/
method = RequestMethod.POST,
/**
* HTTP 요청 헤더가 "Content-Type: application/json;charset=UTF-8"인 것만 처리한다.
* 다른 값이 들어올 경우 org.springframework.web.HttpMediaTypeNotSupportedException을 발생시킨다.
* HTTP 요청 헤더에 명시된 Content-Type은 HTTP 요청 바디의 형식을 의미한다. 즉, 서버에서는 JSON 형식의 바디만 처리하겠다는 의미이다.
* 참고로 GET 요청은 바디를 가지지 않으므로 아래 파라메터를 명시할 필요가 없다.
*/
consumes = MediaType.APPLICATION_JSON_UTF8_VALUE,
/**
* HTTP 응답 헤더로 "Content-Type: application/json;charset=UTF-8"을 반환한다.
* 생략할 경우 메써드 리턴 타입에 따라 Content-Type을 자동으로 판단하여 반환한다.
*/
produces = MediaType.APPLICATION_JSON_UTF8_VALUE
)
메써드 아규먼트 레벨
특정 어노테이션 없이 POJO 클래스를 아규먼트로 명시하면 HTTP 요청 메시지의 QueryString 문자열을 변환하여 저장한다.
@Valid: JSR-303 (Bean Validation) 스펙에 명시된 어노테이션으로
요청 파라메터에 대한 유효성 검사가 가능하다. 유효성 검사 실패시
org.springframework.validation.BindException이 발생한다.
대상 아규먼트는 기본 타입 및 POJO 타입 모두 가능하다.
@RequestBody: HTTP 요청 메시지의 BODY를 변환하여 담을 아규먼트 앞에 명시한다.
HTTP 스펙에 따라 GET 이외의 메써드에서만 명시 가능하다.
(무시하고 명시할 경우 org.springframework.http.converter.HttpMessageNotReadableException이 발생한다.)
한편 앞서 설명한 @Valid를 추가로 명시할 수 있다. 유효성 검사 실패시
org.springframework.web.bind.MethodArgumentNotValidException을 발생시킨다.
클래스 레벨
Spring Web MVC의 @Controller 클래스에서 클래스 레벨에 명시 가능한 어노테이션은 아래와 같다.
@ResponseBody: 모든 메써드의 리턴 오브젝트를 적절한 형태로 변환 후 HTTP 응답 메시지의 바디에 담아 반환한다.
(오브젝트에서 바디로의 실제 변환은 HttpMessageConverter 인터페이스의 각 구현 클래스들이 수행한다.
예를 들면 String 리턴 타입은 StringHttpMessageConverter가 변환을 담당한다.)
클래스 레벨에 명시하면 View로의 반환을 완전히 배제하기 때문에 REST API 구현시 적합하다.
@RestController: @Controller에 위에 설명한 @ResponseBody를 추가한 효과를 가진다.
REST API 구현을 염두한 축약형 어노테이션이다.
@RequestMapping: 응답을 수행할 HTTP 요청을 명시할 수 있다.
path (String, String[]): 요청 URI를 명시한다. 배열을 통한 복수개의 요청 URI를 지정할 수 있다.
클래스 레벨에 명시한 값은 모든 메써드 레벨에 명시한 path 값 앞에 붙어 접두어 역할을 한다.
@RequestMapping("/v1/players")
@PropertySource: 프라퍼티 소스를 명시할 수 있다. 필드 레벨에서 @Value 등을 통해 클래스 레벨에서 명시한 프라퍼티 소스의 값을 주입할 수 있다.
// ROOT CLASSPATH(/src/main/java/resources)에 위치한 some.properties를 프라퍼티 소스로 명시한다.
@PropertySource("classpath:/some.properties")
클래스 필드 레벨
필드 레벨에 명시 가능한 어노테이션은 아래와 같다.
@Autowired: 적합한 이름의 스프링 빈을 자동으로 주입한다. 명백하게 1개의 스프링 빈만 존재할 경우 사용한다.
@Resource: 지정한 이름의 스프링 빈을 주입한다. 같은 타입의 스프링 빈이 2개 이상 존재할 경우 사용한다.
name (String): 주입할 스프링 빈의 이름이다.
@Value: 시스템 환경 변수, Java 환경 변수, Spring 환경 변수, 프라퍼티 리소스 상수 등의 값을 주입한다.
메써드 레벨
@RequestMapping: 메써드가 어떤 HTTP 요청을 처리할 것인가를 작성한다. 구체적인 작성 예는 아래와 같다.
@RequestMapping(
/**
* HTTP URI가 "/users"인 것만 처리한다. 만약 앞서 클래스 레벨에서 "/v1"이 명시되었다면 "/v1/users"를 처리하게 된다.
*/
path = "/users",
/**
* HTTP 요청 메써드가 "POST"인 것만 처리한다.
*/
method = RequestMethod.POST,
/**
* HTTP 요청 헤더가 "Content-Type: application/json;charset=UTF-8"인 것만 처리한다.
* 다른 값이 들어올 경우 org.springframework.web.HttpMediaTypeNotSupportedException을 발생시킨다.
* HTTP 요청 헤더에 명시된 Content-Type은 HTTP 요청 바디의 형식을 의미한다. 즉, 서버에서는 JSON 형식의 바디만 처리하겠다는 의미이다.
* 참고로 GET 요청은 바디를 가지지 않으므로 아래 파라메터를 명시할 필요가 없다.
*/
consumes = MediaType.APPLICATION_JSON_UTF8_VALUE,
/**
* HTTP 응답 헤더로 "Content-Type: application/json;charset=UTF-8"을 반환한다.
* 생략할 경우 메써드 리턴 타입에 따라 Content-Type을 자동으로 판단하여 반환한다.
*/
produces = MediaType.APPLICATION_JSON_UTF8_VALUE
)
메써드 아규먼트 레벨
특정 어노테이션 없이 POJO 클래스를 아규먼트로 명시하면 HTTP 요청 메시지의 QueryString 문자열을 변환하여 저장한다.
@Valid: JSR-303 (Bean Validation) 스펙에 명시된 어노테이션으로
요청 파라메터에 대한 유효성 검사가 가능하다. 유효성 검사 실패시
org.springframework.validation.BindException이 발생한다.
대상 아규먼트는 기본 타입 및 POJO 타입 모두 가능하다.
@RequestBody: HTTP 요청 메시지의 BODY를 변환하여 담을 아규먼트 앞에 명시한다.
HTTP 스펙에 따라 GET 이외의 메써드에서만 명시 가능하다.
(무시하고 명시할 경우 org.springframework.http.converter.HttpMessageNotReadableException이 발생한다.)
한편 앞서 설명한 @Valid를 추가로 명시할 수 있다. 유효성 검사 실패시
org.springframework.web.bind.MethodArgumentNotValidException을 발생시킨다.
JSP에서 웹 애플리케이션의 절대 주소 획득하기
JSP에서 웹 애플리케이션의 절대 주소 획득하기
웹 개발시에는 일반적으로 상대 주소를 사용하여 개발한다.
Java EE 기반의 웹 애플리케이션 개발시 JSTL(JavaServer Pages Standard Tag Library)을
사용하여 JSP(JavaServer Pages)를 구현하는 것은 가장 간단하면서 효율적인 방법이다.
JSP 내에서 페이지 리다이렉션 및 AJAX(Asynchronous JavaScript and XML) 요청 등 필요에
의해 애플리케이션의 주소를 다룰 때 대부분은 <c:url value="" /> 태그를 사용하여 상대 주소를 구현하는 방법을 사용한다.
하지만 가끔씩 절대 주소가 필요할 때가 있다.
절대 주소는 어떻게 획득할까?
javax.servlet.http.HttpServletRequest 오브젝트가 제공하는 정보를 활용하면 절대 주소를 획득하는 것이 가능하다.
JSP에서는 아래와 같이 해당 정보를 획득할 수 있다.
${pageContext.request.scheme}: http
${pageContext.request.serverName}: localhost
${pageContext.request.serverPort}: 8080
${pageContext.request.contextPath}: /someApp
JSP에서 구현된 JavaScript에서는 위 정보를 활용하여 아래와 같이 웹 애플리케이션의 절대 주소를 획득할 수 있다.
var absoluteUrl = '${pageContext.request.scheme}' + '://' + '${pageContext.request.serverName}' + ':' + '${pageContext.request.serverPort}' + '${pageContext.request.contextPath}';
웹 개발시에는 일반적으로 상대 주소를 사용하여 개발한다.
Java EE 기반의 웹 애플리케이션 개발시 JSTL(JavaServer Pages Standard Tag Library)을
사용하여 JSP(JavaServer Pages)를 구현하는 것은 가장 간단하면서 효율적인 방법이다.
JSP 내에서 페이지 리다이렉션 및 AJAX(Asynchronous JavaScript and XML) 요청 등 필요에
의해 애플리케이션의 주소를 다룰 때 대부분은 <c:url value="" /> 태그를 사용하여 상대 주소를 구현하는 방법을 사용한다.
하지만 가끔씩 절대 주소가 필요할 때가 있다.
절대 주소는 어떻게 획득할까?
javax.servlet.http.HttpServletRequest 오브젝트가 제공하는 정보를 활용하면 절대 주소를 획득하는 것이 가능하다.
JSP에서는 아래와 같이 해당 정보를 획득할 수 있다.
${pageContext.request.scheme}: http
${pageContext.request.serverName}: localhost
${pageContext.request.serverPort}: 8080
${pageContext.request.contextPath}: /someApp
JSP에서 구현된 JavaScript에서는 위 정보를 활용하여 아래와 같이 웹 애플리케이션의 절대 주소를 획득할 수 있다.
var absoluteUrl = '${pageContext.request.scheme}' + '://' + '${pageContext.request.serverName}' + ':' + '${pageContext.request.serverPort}' + '${pageContext.request.contextPath}';
2017년 8월 21일 월요일
로마서 1장
로마서 1장 [개역개정]
21.하나님을 알되 하나님을 영화롭게도 아니하며 감사하지도 아니하고 오히려 그 생각이 허망하여지며 미련한 마음이 어두워졌나니
22.스스로 지혜 있다 하나 어리석게 되어
23.썩어지지 아니하는 하나님의 영광을 썩어질 사람과 새와 짐승과 기어다니는 동물 모양의 우상으로 바꾸었느니라
24.그러므로 하나님께서 그들을 마음의 정욕대로 더러움에 내버려 두사 그들의 몸을 서로 욕되게 하게 하셨으니
25.이는 그들이 하나님의 진리를 거짓 것으로 바꾸어 피조물을 조물주보다 더 경배하고 섬김이라 주는 곧 영원히 찬송할 이시로다 아멘
21.하나님을 알되 하나님을 영화롭게도 아니하며 감사하지도 아니하고 오히려 그 생각이 허망하여지며 미련한 마음이 어두워졌나니
22.스스로 지혜 있다 하나 어리석게 되어
23.썩어지지 아니하는 하나님의 영광을 썩어질 사람과 새와 짐승과 기어다니는 동물 모양의 우상으로 바꾸었느니라
24.그러므로 하나님께서 그들을 마음의 정욕대로 더러움에 내버려 두사 그들의 몸을 서로 욕되게 하게 하셨으니
25.이는 그들이 하나님의 진리를 거짓 것으로 바꾸어 피조물을 조물주보다 더 경배하고 섬김이라 주는 곧 영원히 찬송할 이시로다 아멘
2017년 8월 20일 일요일
자바기초
자바 플랫폼, 마이크로 에디션 (Java Platform, Micro Edition, 약칭 Java ME)
モバイル環境向けJavaプラットフォームです。
処理速度、データ容量などリソースが乏しい環境でもスムーズに
Javaアプリが動作するように最適化されています。
主要APIはカーナビ、セットトップボックスなど比較的大きめの端末向けのCDCと、
PDA・携帯電話など比較的小さめの端末向けのCLDCに分かれています。
CLDCの元で動作するJVMは特にKVMと呼ばれ（KはKバイトのメモリで動作の意味）、
モバイル端末のリソースに合わせ最適化されています。
자바 플랫폼, 스탠더드 에디션 (Java Platform, Standard Edition, 약칭 Java SE)
すべてのJavaにおいて基本となるプラットフォームです。
一般にデスクトップ環境向けJavaプラットフォームと言われています。
業務用ソフト、アプリ開発ソフトなどクライアントPCで動作するアプリケーションの開発で
よく使用されます。主要APIにはSwing（GUIアプリ開発）、
Applet（Webブラウザアプリ開発）、
JDBC（DB接続）などがあります。
자바 플랫폼, 엔터프라이즈 에디션 (Java Platform, Enterprise Edition, 약칭 Java EE)
サーバサイドで動作するアプリケーション向けのJavaプラットフォームです。
オンラインショップ、会員制サイトなどWebアプリケーションの開発でよく使用されます。
主要APIには、サーブレット（Webアプリ開発）、
JSP（スクリプトベースWebアプリ開発）、
EJB（DB、トランザクション管理）などがあります。
Java Card
スマートカード（IC搭載カード）環境向けJavaプラットフォームです。
Java Card環境を実装したスマートカードであれば、
スマートカード発行会社を問わず、
同一のJavaアプリを動作させることができます。
Java(JDK)インストール方法(Windows環境)
Java SE Development Kit （JDK）は
Java SEプラットフォームに対応した開発ツールです。
RPM 패키지 매니저
최근 버전 4.11.2 / 2014년 2월 13일(3년 전)
원저자 레드햇
라이선스 GNU 일반 공중 사용 허가서
RPM 패키지 매니저(RPM Package Manager←Red Hat Package Manager)는
원래 레드햇에서 사용되었던 패키지 파일이었지만 현재는 많은 RPM 기반 배포판이 사용되고 있다.
이는 두 가지를 말하는데, 하나는 RPM 패키지 그 자체와 또 하나는 RPM 패키지를 관리하기 위한 도구이다.
RPM을 사용하면 각종 소프트웨어의 설치 및 업데이트를 굉장히 편리하게 할 수 있다.
RPM은 Linux Standard Base의 표준 패키지 포맷 중 하나이다.
원래 레드햇 리눅스를 위한 것이었지만 많은 리눅스 배포판 및 노벨 넷웨어 (6.5 SP3 이후), IBM AIX 5 등으로 이식되었다.
현재의 이름 "RPM"은 재귀 약자의 일종이다.
Yum
개발자 Seth Vidal
최근 버전 3.4.3 / 2011년 6월 28일(6년 전)
프로그래밍 언어 파이썬
종류 패키지 관리
http://yum.baseurl.org/
Yum은 Yellow dog Updater, Modified의 약자로 RPM 기반의 시스템을 위한
자동 업데이터 겸 패키지 설치/제거 도구이다. 듀크 대학교의 Linux@DUKE 프로젝트의 일부분으로 개발되었다.
yumex 같은 GUI 기반 확장 도구도 있다.
Yum 이전에 있었던 Yellowdog Updater (YUP) 도구를 대체하며,
듀크 대학교 물리학부에서 사용되었던 레드햇 리눅스 시스템 관리를 위해서 등장하였다.
그 이후로 페도라, CentOS 등 많은 RPM 기반 리눅스 배포판에서 사용되었다.
레드햇의 패키지 관리자 up2date에서도 Yum 저장소에 접근할 수 있다.
현재 GNU 일반 공중 사용 허가서 버전 2 이상으로 사용 가능하다.
Yum은 페도라 22 버전 이후부터 DNF로 전환되고 있다.
그러나 여전히 Yum의 전신인 rpm, 그리고 후신인 DNF와 같이 사용 가능하다.
어드밴스트 패키징 툴
어드밴스트 패키징 툴(Advanced Packaging Tool, APT)은
코어 라이브러리와 함께 동작하는 자유 사용자 인터페이스로, 데비안 GNU/리눅스 배포판 계열 배포판에서 소프트웨어를
설치하고 제거하는 일을 한다. APT는 이진 파일로부터나 소스 코드 컴파일을 통하여 소프트웨어 패키지의 확인, 구성, 설치를
자동화함으로써 유닉스 계열 컴퓨터 시스템 상의 소프트웨어를 관리하는 작업을 단순하게 만든다.
APT는 본래 데비안의 .deb 패키지와 함께 동작할 목적으로 dpkg를 위한 프론트엔드로
고안되었으나 그 뒤로 apt-rpm을 통한 RPM 패키지 매니저 시스템과도 함께 동작하도록 수정되었다.
Fink 프로젝트가 일부 패키지 관리 작업을 위하여 APT를 Mac OS X에 포팅하였으며 APT는
오픈솔라리스에서도 사용할 수 있다. (Nexenta OS 배포판에도 포함되어 있음).
최근 버전 1.0.9.8.3[1] / 2016년 3월 16일(16달 전)
프로그래밍 언어 C++
dpkg
원저자 이안 머독 (Ian Murdock)
개발자 dpkg 팀
dpkg는 데비안 패키지 관리 시스템의 기초가 되는 소프트웨어이다.
dpkg 명령어가 .deb 패키지의 설치, 삭제, 정보 제공을 위해 사용된다.
dpkg 그 자체는 저레벨의 도구이며, APT와 같은 고급 도구들이
복잡한 패키지 관계와 패키지를 원격에서 받아오는 등의 일을 한다.
앱티튜드 (Aptitude), 시냅틱 (Synaptic) 등이 dpkg 자체보다 많이 쓰이는데,
패키지 의존성을 다루는 더 많은 방법과 더 이해하기 편한 인터페이스를 갖고 있기 때문이다.
데비안 패키지 "dpkg"는 dpkg 프로그램과 더불어 패키징 시스템이
작동하게 하는 dpkg-statoverride, dpkg-divert, dpkg-trigger and update-alternatives 외의
몇몇 프로그램을 설치한다. dpkg는 start-stop-daemon, install-info와 같은 프로그램을 설치하며,
install-info는 일반적으로 하위 호환성을 위해 남겨진다. (현재는 별도로 개발, 배포된다.)
데비안 패키지 "dpkg-dev"는 아래에 설명된 다양한 도구들을 포함하고 있다.
dpkg는 원래 맷 웰쉬, 카를 스트리터와 이안 머독에 의해 펄 프로그램으로써 개발되었으며 1994년에 대부분이
이안 잭슨에 의해 C로 다시 쓰여졌다. dpkg라는 이름은 "데비안 패키지(Debian package)"의 약자였으나,
이 프로그램이 .deb 패키지 포맷의 시초였던 만큼, 데비안 패키지가 작동하는 방식이 변경하는 만큼 새롭게 변경되고 있다.
# rpm -ivh jdk-8u40-linux-x64.rpm
export JAVA_HOME=/usr/java/jdk1.8.0_40
export PATH=$PATH:$HOME/bin:$JAVA_HOME/bin
public class HelloWorld {
public static void main (String[] args) {
System.out.println("Hello World !!");
}
}
いっち 一致 일치
추석
2017년 10월 4일(수) (10월 3일~10월 6일-대체휴일 포함)
한 해의 추수를 감사하는 우리나라 명절
설날
2018년 2월 16일(금) (2월 15일~2월 17일)
한 해의 건강과 풍요를 기원하는 우리나라 명절
しゅうしょく [修飾]
수식. 아름답게 꾸밈.
きまりきる [決まり切る,極り切る]
완전히 확정되어 있음, 또는, 완전히 딱 들어맞음
とめる
止める,留める,停める 세우다, 멈추다.
java.lang
java.io
-classpathオプションの使用例
java -classpath C:\JavaClass1 HelloWorld
java -classpath C:\JavaClass1;C:\JavaClass2 HelloWorld
java -classpath C:\JavaArchive1\archive.jar HelloWorld
すいしょう 推奨
1.추장
2.추천하여 권함
C:\>set CLASSPATH=．；C：\JavaClass1
rt.jar、i18n.jarは-classpathオプション、
CLASSPATH環境変数の状態に関わらずクラスパスに設定されています。
rt.jarにはJavaコアクラスがi18n.jarには国際化関連クラスが格納されています。
整数型
型 デフォルト値 サイズ 範囲
byte 0 8bit -128 ～ 127
short 0 16bit -32768 ～ 32767
int 0 32bit -2147483648 ～ 2147483647
long 0 64bit -9223372036854775808 ～ 9223372036854775807
浮動小数点型
型 デフォルト値 サイズ 範囲
float 0.0 32bit 約(-)3.40282347E+38（約6～7桁の精度）
double 0.0 64bit (-)1.79769313486231570E+388（15桁の精度）
その他
型 デフォルト値 サイズ 範囲
char \u0000 16bit \u0000 ～ \uFFFF
boolean false 1bit true、false
モバイル環境向けJavaプラットフォームです。
処理速度、データ容量などリソースが乏しい環境でもスムーズに
Javaアプリが動作するように最適化されています。
主要APIはカーナビ、セットトップボックスなど比較的大きめの端末向けのCDCと、
PDA・携帯電話など比較的小さめの端末向けのCLDCに分かれています。
CLDCの元で動作するJVMは特にKVMと呼ばれ（KはKバイトのメモリで動作の意味）、
モバイル端末のリソースに合わせ最適化されています。
자바 플랫폼, 스탠더드 에디션 (Java Platform, Standard Edition, 약칭 Java SE)
すべてのJavaにおいて基本となるプラットフォームです。
一般にデスクトップ環境向けJavaプラットフォームと言われています。
業務用ソフト、アプリ開発ソフトなどクライアントPCで動作するアプリケーションの開発で
よく使用されます。主要APIにはSwing（GUIアプリ開発）、
Applet（Webブラウザアプリ開発）、
JDBC（DB接続）などがあります。
자바 플랫폼, 엔터프라이즈 에디션 (Java Platform, Enterprise Edition, 약칭 Java EE)
サーバサイドで動作するアプリケーション向けのJavaプラットフォームです。
オンラインショップ、会員制サイトなどWebアプリケーションの開発でよく使用されます。
主要APIには、サーブレット（Webアプリ開発）、
JSP（スクリプトベースWebアプリ開発）、
EJB（DB、トランザクション管理）などがあります。
Java Card
スマートカード（IC搭載カード）環境向けJavaプラットフォームです。
Java Card環境を実装したスマートカードであれば、
スマートカード発行会社を問わず、
同一のJavaアプリを動作させることができます。
Java(JDK)インストール方法(Windows環境)
Java SE Development Kit （JDK）は
Java SEプラットフォームに対応した開発ツールです。
RPM 패키지 매니저
최근 버전 4.11.2 / 2014년 2월 13일(3년 전)
원저자 레드햇
라이선스 GNU 일반 공중 사용 허가서
RPM 패키지 매니저(RPM Package Manager←Red Hat Package Manager)는
원래 레드햇에서 사용되었던 패키지 파일이었지만 현재는 많은 RPM 기반 배포판이 사용되고 있다.
이는 두 가지를 말하는데, 하나는 RPM 패키지 그 자체와 또 하나는 RPM 패키지를 관리하기 위한 도구이다.
RPM을 사용하면 각종 소프트웨어의 설치 및 업데이트를 굉장히 편리하게 할 수 있다.
RPM은 Linux Standard Base의 표준 패키지 포맷 중 하나이다.
원래 레드햇 리눅스를 위한 것이었지만 많은 리눅스 배포판 및 노벨 넷웨어 (6.5 SP3 이후), IBM AIX 5 등으로 이식되었다.
현재의 이름 "RPM"은 재귀 약자의 일종이다.
Yum
개발자 Seth Vidal
최근 버전 3.4.3 / 2011년 6월 28일(6년 전)
프로그래밍 언어 파이썬
종류 패키지 관리
http://yum.baseurl.org/
Yum은 Yellow dog Updater, Modified의 약자로 RPM 기반의 시스템을 위한
자동 업데이터 겸 패키지 설치/제거 도구이다. 듀크 대학교의 Linux@DUKE 프로젝트의 일부분으로 개발되었다.
yumex 같은 GUI 기반 확장 도구도 있다.
Yum 이전에 있었던 Yellowdog Updater (YUP) 도구를 대체하며,
듀크 대학교 물리학부에서 사용되었던 레드햇 리눅스 시스템 관리를 위해서 등장하였다.
그 이후로 페도라, CentOS 등 많은 RPM 기반 리눅스 배포판에서 사용되었다.
레드햇의 패키지 관리자 up2date에서도 Yum 저장소에 접근할 수 있다.
현재 GNU 일반 공중 사용 허가서 버전 2 이상으로 사용 가능하다.
Yum은 페도라 22 버전 이후부터 DNF로 전환되고 있다.
그러나 여전히 Yum의 전신인 rpm, 그리고 후신인 DNF와 같이 사용 가능하다.
어드밴스트 패키징 툴
어드밴스트 패키징 툴(Advanced Packaging Tool, APT)은
코어 라이브러리와 함께 동작하는 자유 사용자 인터페이스로, 데비안 GNU/리눅스 배포판 계열 배포판에서 소프트웨어를
설치하고 제거하는 일을 한다. APT는 이진 파일로부터나 소스 코드 컴파일을 통하여 소프트웨어 패키지의 확인, 구성, 설치를
자동화함으로써 유닉스 계열 컴퓨터 시스템 상의 소프트웨어를 관리하는 작업을 단순하게 만든다.
APT는 본래 데비안의 .deb 패키지와 함께 동작할 목적으로 dpkg를 위한 프론트엔드로
고안되었으나 그 뒤로 apt-rpm을 통한 RPM 패키지 매니저 시스템과도 함께 동작하도록 수정되었다.
Fink 프로젝트가 일부 패키지 관리 작업을 위하여 APT를 Mac OS X에 포팅하였으며 APT는
오픈솔라리스에서도 사용할 수 있다. (Nexenta OS 배포판에도 포함되어 있음).
최근 버전 1.0.9.8.3[1] / 2016년 3월 16일(16달 전)
프로그래밍 언어 C++
dpkg
원저자 이안 머독 (Ian Murdock)
개발자 dpkg 팀
dpkg는 데비안 패키지 관리 시스템의 기초가 되는 소프트웨어이다.
dpkg 명령어가 .deb 패키지의 설치, 삭제, 정보 제공을 위해 사용된다.
dpkg 그 자체는 저레벨의 도구이며, APT와 같은 고급 도구들이
복잡한 패키지 관계와 패키지를 원격에서 받아오는 등의 일을 한다.
앱티튜드 (Aptitude), 시냅틱 (Synaptic) 등이 dpkg 자체보다 많이 쓰이는데,
패키지 의존성을 다루는 더 많은 방법과 더 이해하기 편한 인터페이스를 갖고 있기 때문이다.
데비안 패키지 "dpkg"는 dpkg 프로그램과 더불어 패키징 시스템이
작동하게 하는 dpkg-statoverride, dpkg-divert, dpkg-trigger and update-alternatives 외의
몇몇 프로그램을 설치한다. dpkg는 start-stop-daemon, install-info와 같은 프로그램을 설치하며,
install-info는 일반적으로 하위 호환성을 위해 남겨진다. (현재는 별도로 개발, 배포된다.)
데비안 패키지 "dpkg-dev"는 아래에 설명된 다양한 도구들을 포함하고 있다.
dpkg는 원래 맷 웰쉬, 카를 스트리터와 이안 머독에 의해 펄 프로그램으로써 개발되었으며 1994년에 대부분이
이안 잭슨에 의해 C로 다시 쓰여졌다. dpkg라는 이름은 "데비안 패키지(Debian package)"의 약자였으나,
이 프로그램이 .deb 패키지 포맷의 시초였던 만큼, 데비안 패키지가 작동하는 방식이 변경하는 만큼 새롭게 변경되고 있다.
# rpm -ivh jdk-8u40-linux-x64.rpm
export JAVA_HOME=/usr/java/jdk1.8.0_40
export PATH=$PATH:$HOME/bin:$JAVA_HOME/bin
public class HelloWorld {
public static void main (String[] args) {
System.out.println("Hello World !!");
}
}
いっち 一致 일치
추석
2017년 10월 4일(수) (10월 3일~10월 6일-대체휴일 포함)
한 해의 추수를 감사하는 우리나라 명절
설날
2018년 2월 16일(금) (2월 15일~2월 17일)
한 해의 건강과 풍요를 기원하는 우리나라 명절
しゅうしょく [修飾]
수식. 아름답게 꾸밈.
きまりきる [決まり切る,極り切る]
완전히 확정되어 있음, 또는, 완전히 딱 들어맞음
とめる
止める,留める,停める 세우다, 멈추다.
java.lang
java.io
-classpathオプションの使用例
java -classpath C:\JavaClass1 HelloWorld
java -classpath C:\JavaClass1;C:\JavaClass2 HelloWorld
java -classpath C:\JavaArchive1\archive.jar HelloWorld
すいしょう 推奨
1.추장
2.추천하여 권함
C:\>set CLASSPATH=．；C：\JavaClass1
rt.jar、i18n.jarは-classpathオプション、
CLASSPATH環境変数の状態に関わらずクラスパスに設定されています。
rt.jarにはJavaコアクラスがi18n.jarには国際化関連クラスが格納されています。
整数型
型 デフォルト値 サイズ 範囲
byte 0 8bit -128 ～ 127
short 0 16bit -32768 ～ 32767
int 0 32bit -2147483648 ～ 2147483647
long 0 64bit -9223372036854775808 ～ 9223372036854775807
浮動小数点型
型 デフォルト値 サイズ 範囲
float 0.0 32bit 約(-)3.40282347E+38（約6～7桁の精度）
double 0.0 64bit (-)1.79769313486231570E+388（15桁の精度）
その他
型 デフォルト値 サイズ 範囲
char \u0000 16bit \u0000 ～ \uFFFF
boolean false 1bit true、false
2017년 8월 18일 금요일
2017년 8월 16일 수요일
소프트웨어 아키텍처란?
https://msdn.microsoft.com/ko-kr/hh144976.aspx
소프트웨어 아키텍처란?
소프트웨어 아키텍처 프로세스에서는 고객 요구 사항을 수집 및 분석하고 이러한 요구 사항을 충족하는 소프트웨어의 설계를 만듭니다. 성공적인 소프트웨어 설계는 상충하는 요구 사항으로 인해 발생하는 필연적인 타협점 간의 균형을 맞추고, 오랜 시간에 걸쳐 발전한 설계 원칙과 실행 기법을 준수하고, 최신 하드웨어, 네트워킹 및 관리 시스템을 보완해야 합니다. 강력한 소프트웨어 아키텍처에는 이론 및 실무 주제에 대한 풍부한 경험과 막연한 비즈니스 시나리오 및 요구 사항을 구체적이고 실용적인 설계로 변환하는 데 필요한 비전이 필요합니다.
소프트웨어 아키텍처에는 모든 기술 및 운영 요구 사항을 충족하는 구조화된 솔루션을 정의하고 성능, 보안, 관리 효율성과 같은 일반적인 품질 특성을 최적화하는 작업이 포함됩니다. 여기에는 광범위한 요소를 기반으로 한 일련의 의사 결정이 필요하며, 이러한 각 의사 결정은 소프트웨어의 품질, 성능, 관리 효율성 및 전체적인 성공에 큰 영향을 미칠 수 있습니다.
근래의 소프트웨어는 독립적으로 실행되는 경우는 거의 없습니다. 대부분의 경우 최소한 소프트웨어 사용자가 작업하는 데 필요한 정보를 제공하는 회사 데이터베이스와 같은 데이터 원본과 상호 작용합니다. 또한 일반적으로 현대 소프트웨어는 다른 서비스 및 네트워크 기능과 상호 작용하여 인증을 수행하고 정보를 획득 및 게시하고 통합 사용자 환경을 제공합니다. 적절한 아키텍처가 없는 경우 소프트웨어를 배포, 운영, 유지 관리하고 다른 시스템과 성공적으로 통합하기가 어렵거나 불가능할 수 있으며 사용자 요구 사항을 충족할 수 없게 됩니다.
소프트웨어 아키텍처는 소프트웨어가 달성해야 하는 목표와 코드로서의 구현 세부 사항을 연결하는 것이라고 생각할 수 있습니다. 올바른 아키텍처를 확보하면 요구 사항과 결과물 간의 연결을 최적화할 수 있습니다. 잘 설계된 소프트웨어는 원래 요구 사항의 매개 변수 내에서 지정된 작업을 수행하며 이 과정에서 성능, 보안, 안정성 등을 최대화합니다.
최상위 수준의 아키텍처 설계는 시스템 구조를 노출하되 구현 세부 사항은 숨기고, 모든 사용 사례와 시나리오를 실현하고, 모든 관계자의 요구 사항을 처리하도록 노력하고, 모든 기능 및 품질 요구 사항을 최대한 충족해야 합니다.
소프트웨어 아키텍처가 왜 중요한가?
응용 프로그램에 대한 사용자의 기대가 커지면서 현재 소프트웨어에 대한 요구 사항도 더 복잡해지고 있습니다. 이제 대부분의 비즈니스 및 상업 시나리오에서 간단한 독립 실행형 데스크톱 응용 프로그램은 부족하게 되었습니다. 현재의 연결된 환경에서 응용 프로그램은 다른 응용 프로그램 및 서비스와 상호 작용하고 클라우드 및 휴대용 장치와 같은 다양한 환경에서 실행되어야 합니다. 과거에 일반적으로 사용된 모놀리식 설계는 프레임워크, 운영 체제, 런타임 호스트 및 네트워크를 사용하여 불과 몇 년 전까지만 해도 없었던 새로운 기능을 구현하는 구성 요소화된 서비스 지향 소프트웨어로 대체되었습니다.
이 복잡성은 설계뿐만 아니라 소프트웨어 배포, 유지 및 관리에도 영향을 미칩니다. 소프트웨어의 TCO(총 소유 비용)는 이제 대부분 배포 후 비용으로 구성됩니다. 잘 설계된 응용 프로그램은 응용 프로그램을 배포하고 실행 상태를 유지하고 변화하는 요구 사항을 총족하도록 업데이트하고 문제를 해결하는 데 필요한 비용과 시간을 줄임으로써 TCO를 최소화합니다. 또한 사용자 지원 및 관리도 간소화합니다.
성공적인 소프트웨어가 되려면 여러 가지 필수적인 기준도 충족해야 합니다. 악의적인 공격과 우연한 잘못으로부터 응용 프로그램과 데이터를 보호할 수 있는 보안 기능을 제공해야 합니다. 오류 및 이와 관련된 비용이 최소화되도록 견고하고 안정적이어야 합니다. 최대 응답 시간 또는 특정 작업 부하 용량과 같은 고객의 요구 사항을 충족하기 위해 필요한 매개 변수 내에서 기능을 수행해야 합니다. 관리 및 지원 비용을 최소화하기 위해 유지 관리가 용이해야 하며, 시간이 경과함에 따라 필요한 변경 및 업그레이드가 가능하도록 충분한 확장성을 갖추어야 합니다.
이러한 모든 요소에는 절충이 수반됩니다. 예를 들어 복잡한 암호화를 통해 가장 안전한 메커니즘을 구현하면 성능은 떨어지게 됩니다. 광범위한 구성 및 업그레이드 옵션을 구현하면 배포 및 관리 작업이 더 복잡해질 수 있습니다. 또한 설계가 복잡할수록 구현 비용도 많이 듭니다. 좋은 아키텍처는 이러한 요소들 간에 균형을 맞추어 특정 시나리오에 대한 최적의 결과를 얻는 것을 목표로 해야 합니다.
소프트웨어 아키텍처는 어떤 역할을 하는가?
소프트웨어 아키텍처의 시작은 요구 사항 집합입니다. 이러한 요구 사항은 다이어그램, 프로세스 순서도, 모델 또는 소프트웨어가 수행해야 하는 운영 작업의 문서화된 목록 형태로 표현됩니다. 일반적으로 고객 또는 파트너는 모양과 느낌 또는 일반적인 작업에 대한 특정 사용자 인터페이스의 작동 방식과 같이 명확하지 않은 요구 사항도 제시합니다. 요구 사항에는 새 소프트웨어가 상호 작용할 기존 소프트웨어, 시스템, 하드웨어 및 네트워크에 대한 정보와, 배포 및 유지 관리 계획, 그리고 물론 프로젝트에서 사용할 수 있는 예산과 같은 다른 요소도 포함되어야 합니다.
소프트웨어 설계자는 고객의 요구를 고려해야 합니다. 그러나 “고객”이라는 일반적인 용어는 일반적으로 비즈니스 요구 사항, 사용자 요구 사항, 시스템 요구 사항이라는 세 가지 상충하는 책임 영역으로 구성됩니다. 비즈니스 요구 사항은 일반적으로 비즈니스 프로세스, 성능 요소(예: 보안, 안정성 및 처리량), 그리고 예산 및 비용 제약과 같은 요소를 정의합니다. 사용자 요구 사항에는 소프트웨어 인터페이스 디자인, 운영 기능 및 사용 편의성이 포함됩니다. 시스템 요구 사항에는 하드웨어, 네트워킹 및 런타임 환경 기능과 제약이 포함됩니다. 그림 1은
일반적인 고객의 상충하는 요구 사항
그림 1 - 일반적인 고객의 상충하는 요구 사항
소프트웨어 설계자에게는 요구 사항을 수집 및 분석하고 아키텍처를 정의하기 위한 자기만의 방법이 있습니다. 설계자는 흔히 “사용자는 어떤 방법으로 응용 프로그램을 사용하게 되는가?”, “응용 프로그램이 프로덕션과 관리 환경에 어떻게 배포되는가?”, “보안, 성능, 동시성, 국제화 및 구성과 같은 응용 프로그램의 품질 특성 요구 사항은 무엇인가?”, “시간이 지나도 유연하고 유지 관리가 가능하도록 응용 프로그램을 설계하려면 어떻게 해야 하는가?” 그리고 “지금 또는 배포된 후 응용 프로그램에 영향을 미칠 수 있는 아키텍처 추세는 무엇인가?”와 같은 질문의 답을 구해야 합니다.
마지막 질문은 흥미로우면서도 중요합니다. 좋은 소프트웨어 설계는 고객의 현재 요구 사항뿐만 아니라 가까운 미래의 요구 사항도 지속적으로 충족합니다. 이는 하드웨어, 구성 요소, 프레임워크, 런타임 플랫폼, 관리 소프트웨어 시스템 및 소프트웨어에 내장되거나 소프트웨어가 통합해야 하는 기타 다양한 기능에 대해 설계자가 내려야 하는 의사 결정에 영향을 미칩니다.
소프트웨어 설계 및 개발 영역의 작업이 대부분 그렇듯이, 아키텍처를 설계하는 일은 선행적이고 반복적인 프로세스입니다. 요구 사항 분석, 기술 연구, 목표 식별과 같은 많은 초기 작업은 일반적으로 프로세스의 시작 부분에서 수행됩니다. 다음 단계는 설계에 대한 주요 시나리오를 확인하는 것입니다. 이는 소프트웨어가 충족해야 하는 기본 요구 사항이자 소프트웨어 운영의 제약 조건이기도 합니다. 설계자는 이 정보를 통해 응용 프로그램의 개요를 도출할 수 있습니다. 이 개요에는 응용 프로그램 유형(웹, 폰, 데스크톱 또는 클라우드), 배포 아키텍처(일반적으로 구성 요소들이 하드웨어와 네트워크 경계를 넘어 통신하는 계층화된 설계), 추종할 적절한 아키텍처 스타일(예: n계층, 클라이언트/서버, 또는 서비스 지향), 그리고 시나리오에 가장 잘 맞는 구현 기술과 같은 전체적인 세부 사항이 포함됩니다.
여기서 설계자는 앞서 파악한 최상위의 가장 중요한 요구 사항을 충족하는 후보 설계들을 생성할 수 있습니다. 이 설계를 많은 경우 고객 및 평가판 또는 테스트 버전의 피드백과 함께 주요 시나리오에 따라 검토 및 테스트해서 최적의 솔루션을 제공하는지 확인합니다. 첫 번째 반복에서 되지 않더라도 주기가 반복됨에 따라 설계는 요구 사항 및 주요 시나리오를 기반으로 수렴하게 됩니다. 그림 2는 이 반복 접근 방식을 보여 줍니다.
반복적인 아키텍처 설계 프로세스
그림 2 – 반복적인 아키텍처 설계 프로세스
설계가 세밀해지고 개별 작업 및 구성 요소가 식별됨에 따라 설계자는 각 단계에서 설계를 더 정제하고 세부 사항을 추가할 수 있습니다. 예를 들어 아키텍처 스타일과 배포 접근 방식이 식별되면 설계자는 계층과 구성 요소 간의 통신에 대한 의사 결정을 내릴 수 있습니다. 여기에는 현재 및 미래 요구 사항을 기반으로 프로토콜을 선택하고, 앞으로 나올 표준에 정의된 새로운 기술과 기능을 사전에 검토하는 작업이 포함될 수 있습니다.
설계자 작업의 최종 결과물은 일반적으로 여러 관점에서 응용 프로그램을 정의하는 설계도, 모델 및 문서 집합입니다. 이러한 요소들이 결합되면 개발자, 테스트 팀, 관리자 및 경영진에게 설계를 구현하는 데 필요한 모든 정보가 제공됩니다. 이 정보에는 구성 요소와 응용 프로그램 계층의 구조 및 레이아웃에 대한 설명, 로깅 및 유효성 검사와 같은 크로스 커팅(Cross-Cutting) 사안이 처리되는 방법, 테스트 및 배포 계획, 개발자, 관리자 및 지원 담당자를 지원하기 위한 문서가 포함됩니다.
최종 설계는 응용 프로그램이 충족해야 하는 품질 특성도 지정해야 합니다. 이는 설계자가 고객과 상담하면서 내린 신중한 의사 결정과 타협의 결과입니다. 여기에는 보안 요구 사항과 보안 구현 계획, 대상 플랫폼에 배포될 경우 필요한 확장성과 성능, 유지 관리 용이성과 확장성이 구현되는 방식, 다른 시스템과의 상호 운용성을 가능하게 하는 기능에 대한 정의가 포함됩니다.
소프트웨어 설계자에게 필요한 기술은 무엇인가?
소프트웨어 설계자에게 다양한 소프트 스킬과 하드 스킬이 모두 필요하다는 것은 분명합니다. 요구 사항 분석 및 검토 단계에서 설계자는 고객과 협력하고 파트너 및 다른 팀 구성원과 상담하고 관리자, 사용자 및 시스템 관리자 사이의 중개자 역할을 해야 합니다. 이러한 소프트 스킬이 뛰어나면 더 나은 초기 계획과 더 정확한 요구 사항 집합을 만들 수 있으므로 이후 시간과 노력을 덜 수 있습니다.
소프트웨어 설계자는 최신 소프트웨어 시스템, 프레임워크 및 하드웨어가 요구 사항에 대응하는 방식, 네트워킹 및 운영 체제 요소가 설계 의사 결정에 미치는 영향, 이러한 영역의 추세와 변화가 설계에 미칠 영향을 이해하기 위해 필요한 하드 스킬도 갖추어야 합니다. 초기 요구 사항 분석 후 소프트웨어 설계자는 설계 패턴, 통신 및 메시징 표준, 코드 기능, 보안 관련 사항과 성능 제약에 대한 하드 스킬도 적용해야 합니다. 이러한 모든 요소에는 최종 소프트웨어를 구현하는 데 사용될 기술에 대한 풍부한 지식이 필요합니다.
물론 소프트웨어 아키텍처에는 비전도 필요합니다. 설계자는 여러 시스템이 연계되어 상호 운용되는 방법, 이러한 시스템이 분할 및 배포되는 방법, 그리고 사용자와 시스템이 상호 작용하는 방법을 파악하려면 먼저 전체적인 솔루션을 마음 속에 그릴 수 있어야 합니다. 그렇게 하기 위해서는 모든 요구 사항과 제약을 대조 및 파악하고, 유연하고 포괄적인 기술 설계에서 이러한 요소들을 점진적으로 변형시켜 나가기 위한 체계적인 접근 방법과 세부 사항에 대한 세심한 주의가 필요합니다. 또한 최종 결과를 시각화한 다음 이상적인 솔루션을 향해 조직적으로 작업해 나갈 수 있는 직감과 상상력도 필요합니다.
クラス図
統一モデリング言語 (UML)におけるクラス図（クラスず、英: class diagram）とは、クラス、属性、クラス間の関係からシステムの構造を記述する静的な構造図である。
クラス図とソースコードの同期が可能なUMLモデリングツールも存在する。
目次
1 クラス
2 関係
2.1 インスタンスレベルの関係
2.1.1 リンク
2.1.2 関連
2.1.3 集約
2.1.4 コンポジション
2.1.5 集約とコンポジションの違い
2.2 クラスレベルの関係
2.2.1 汎化・特化
2.2.2 実現
2.3 一般的な関係
2.3.1 依存
2.3.2 多重度
3 関連項目
4 外部リンク
クラス
クラス図におけるクラスの例
ソフトウェアシステムにおけるクラスは、中にクラス名の記述された四角で表現する。クラスはドメイン等、ソフトウェア要素ではない要素であっても良い。（訳注：例えば、車のタイヤであったり、化学物質の一種であったり、料理の材料であるかも知れない）
オプションとして、クラス名の下に属性（つまりプロパティ）の区画を設けることができる。どの属性も最低でも名前を記述せねばならず、オプションとしてその型、初期値、その他の特性を記述することができる。
更にその下に、クラスの関数（つまりメソッド）の区画を設けることができる。どの関数も最低でも名前を記述せねばならず、オプションとしてその引数や戻り値を記述することができる。
他の区画を定義しても良い。例えば、保存する義務や必要条件、制限などである。
属性と関数には以下の可視性を付けることができる：
" + "はpublic
" # "はprotected
" - "はprivate
" ~ "はpackage（パッケージ内で可視）
また、クラス図でクラス変数やクラス関数を表現するには、区画内の項目に下線を引けばよい。
関係
関係は、クラス図とオブジェクト図に見られる、以下に示すような論理的な連結の種類を総称する用語である。
このように関係という用語は列挙により定義されるのみなので、その本質に関する具体的イメージをつかみにくい。そこであえて大雑把にいえば、クラス図においては、関係とは「そのクラスのソースコードに型名が出現する(ことになるであろう)」ことを意味する。オブジェクト図において、関係とは「そのオブジェクトが参照を持っている(ことになるであろう)」ことを意味する。
なお、いうまでもないことだが、クラス図に出現するすべてのクラスは、同一のクラス図(あるいはシステム)に出現するという論理的なつながりを持っているので、単に関係を「論理的な連結」とだけ定義すると概念が破たんする。
UMLでは、以下の関係を表現できる。
インスタンスレベルの関係
リンク
リンクとは、基本的なオブジェクト間の関係である。クラスを表す四角を二つ以上、線でつなぐことで表現する。これはオブジェクト図にも見られる。オブジェクト図では、インスタンスの関連を示す。
関連
関連は、リンクの一種である。オブジェクト間の関係は線で表現する。三つ以上の関連を表現することもできる。そのような場合、各オブジェクトから出た線は菱形に接続される。（訳注：これをN項関係という）
集約
2つのクラス間の集約を表すクラス図
集約とは、"has-a" もしくは関連の一種であるが、特殊な関係である。関連の一種で、名前付けなど「関連」で可能なオプションを付けることができる。しかし、集約は二つ以上のクラスを含むことができない。（訳注：つまり、集約にはN項関係は存在し得ない）
集約は、一方がもう一方のクラスの一部であるが、両クラス間に強いライフサイクルの依存が無い場合に使用する。つまり、集約しているクラスのオブジェクトが削除されても、されている側のオブジェクトが消えるとは限らない。
UML では、集約するクラスと集約されるクラスの間を線で結び、集約するクラス側の線の端に中抜きの菱形を記述する事で表現する。
コンポジション
コンポジションとは、"has-a"もしくは関連の変種のより強いものである。集約より特殊である。
コンポジションは、両クラス間に強いライフサイクルの依存がある場合に使用する。つまり、コンポジション関係にあるクラスの集約しているオブジェクトが削除されると、必ず集約されている側のオブジェクトはすべて削除される。
UMLでは、視覚的には黒い菱形を集約する側のクラスの線の端に記述する事で表現する。
集約とコンポジションの違い
すべてのコンポジションは、0..1か1の多重度でなければならない。集約されるインスタンスは、される対象が一つだけでなければおかしいからだ。対して、集約の場合は、これに限らない。
現実世界で全体-部分の関係の例を挙げるとすれば、例えば車に対するエンジンの例が挙げられる。エンジンENG01は車のモデルCM01の部分であり、集約の関係がベストと言える。エンジンとしては、ENG01は他の車のモデルに搭載することも可能だからだ。例えばCM02等。これはしばしば、「カタログ」関係と呼ばれる。
クラスレベルの関係
汎化・特化
KP-UML-Generalization-20060325.svg
汎化の関係とは、関係するクラスの一方（スーパークラス）がもう一方（サブクラス）に対してより一般的であると考えられることを表す。実際問題、これはサブクラスのインスタンスがスーパークラスのインスタンスでもあることを意味している（このタイプの汎化の例は「binomial nomenclature」に見られる：人間は猿のサブタイプであり、猿は哺乳動物のサブタイプであり以下略）。この関係は、'AはB'とすると最も簡単に理解できる（人間は哺乳動物、哺乳動物は動物）。
UMLでの視覚的な記述方法としては、スーパークラス側の線の端に白抜きの三角を描くことで表現する。
汎化・特化の関係は、継承または"is-a"の関係としても知られる。
汎化・特化の関係において、スーパータイプは"親"、"スーパークラス"、"基底クラス"、"規定タイプ"としても知られる。
汎化・特化の関係において、サブタイプは"子"、"サブクラス"、"派生クラス"、"派生タイプ"、"派生型"としても知られる。
特化の関係は、汎化の関係の逆である。つまり、サブタイプはスーパータイプを特化したものである。
この関係が生物学的な親/子の関係との類似を全く持っていない事に注意すること：これらの用語は非常に一般的だが、使用方法によっては紛らわしい場合がある。
汎化 - 特化の関係：
AはBの一種
例えば、"オークは木の一種"、"貨物自動車は車の一種"
実現
実現の関係とは、関係するクラスの一方（クライアント）がもう一方（サプライヤ）の振る舞いを実現していることを表す。（訳注：例えば、抽象クラスやインターフェイスのメソッドの内容をサブクラスで具体的に記述すること）実現は視覚的には、白抜きされた三角を先端に持つ破線で表現する。
一般的な関係
依存
定義されている要素間に、片方を変更すればもう片方に変更が生じる依存が存在する。この関係は、依存する側からされる側への破線矢印で表現する。幾つかの名前付けされた種類がある。依存はインスタンス間、クラス間、インスタンス-クラス間にあり得る。
多重度
関連の関係は、関連するクラスの一方がもう一方を参照していることを意味する。汎化の関係と対比して、'AはBを持っている'というフレーズで最も簡単に理解できる（母猫には子猫がいる、子猫には母猫がいる）。
UMLでは、関係にオブジェクトのロールを矢印で示唆して表現する。オプションとして、それらのエンティティのインスタンスの多重度を両端に記述することができる。多重度とは、その関連に参加するオブジェクトの数を示すものである。一般的な多重度は以下：
記述 インスタンス数
0..1 無しか一つ
1 確実に一つ
0..* または * ゼロ個以上
1..* 1個以上
この関係は、"has-a"の関係としても知られている。
関連項目
ドメインモデル
外部リンク
クラス図とソースコードの同期が可能なUMLモデリングツールも存在する。
目次
1 クラス
2 関係
2.1 インスタンスレベルの関係
2.1.1 リンク
2.1.2 関連
2.1.3 集約
2.1.4 コンポジション
2.1.5 集約とコンポジションの違い
2.2 クラスレベルの関係
2.2.1 汎化・特化
2.2.2 実現
2.3 一般的な関係
2.3.1 依存
2.3.2 多重度
3 関連項目
4 外部リンク
クラス
クラス図におけるクラスの例
ソフトウェアシステムにおけるクラスは、中にクラス名の記述された四角で表現する。クラスはドメイン等、ソフトウェア要素ではない要素であっても良い。（訳注：例えば、車のタイヤであったり、化学物質の一種であったり、料理の材料であるかも知れない）
オプションとして、クラス名の下に属性（つまりプロパティ）の区画を設けることができる。どの属性も最低でも名前を記述せねばならず、オプションとしてその型、初期値、その他の特性を記述することができる。
更にその下に、クラスの関数（つまりメソッド）の区画を設けることができる。どの関数も最低でも名前を記述せねばならず、オプションとしてその引数や戻り値を記述することができる。
他の区画を定義しても良い。例えば、保存する義務や必要条件、制限などである。
属性と関数には以下の可視性を付けることができる：
" + "はpublic
" # "はprotected
" - "はprivate
" ~ "はpackage（パッケージ内で可視）
また、クラス図でクラス変数やクラス関数を表現するには、区画内の項目に下線を引けばよい。
関係
関係は、クラス図とオブジェクト図に見られる、以下に示すような論理的な連結の種類を総称する用語である。
このように関係という用語は列挙により定義されるのみなので、その本質に関する具体的イメージをつかみにくい。そこであえて大雑把にいえば、クラス図においては、関係とは「そのクラスのソースコードに型名が出現する(ことになるであろう)」ことを意味する。オブジェクト図において、関係とは「そのオブジェクトが参照を持っている(ことになるであろう)」ことを意味する。
なお、いうまでもないことだが、クラス図に出現するすべてのクラスは、同一のクラス図(あるいはシステム)に出現するという論理的なつながりを持っているので、単に関係を「論理的な連結」とだけ定義すると概念が破たんする。
UMLでは、以下の関係を表現できる。
インスタンスレベルの関係
リンク
リンクとは、基本的なオブジェクト間の関係である。クラスを表す四角を二つ以上、線でつなぐことで表現する。これはオブジェクト図にも見られる。オブジェクト図では、インスタンスの関連を示す。
関連
関連は、リンクの一種である。オブジェクト間の関係は線で表現する。三つ以上の関連を表現することもできる。そのような場合、各オブジェクトから出た線は菱形に接続される。（訳注：これをN項関係という）
集約
2つのクラス間の集約を表すクラス図
集約とは、"has-a" もしくは関連の一種であるが、特殊な関係である。関連の一種で、名前付けなど「関連」で可能なオプションを付けることができる。しかし、集約は二つ以上のクラスを含むことができない。（訳注：つまり、集約にはN項関係は存在し得ない）
集約は、一方がもう一方のクラスの一部であるが、両クラス間に強いライフサイクルの依存が無い場合に使用する。つまり、集約しているクラスのオブジェクトが削除されても、されている側のオブジェクトが消えるとは限らない。
UML では、集約するクラスと集約されるクラスの間を線で結び、集約するクラス側の線の端に中抜きの菱形を記述する事で表現する。
コンポジション
コンポジションとは、"has-a"もしくは関連の変種のより強いものである。集約より特殊である。
コンポジションは、両クラス間に強いライフサイクルの依存がある場合に使用する。つまり、コンポジション関係にあるクラスの集約しているオブジェクトが削除されると、必ず集約されている側のオブジェクトはすべて削除される。
UMLでは、視覚的には黒い菱形を集約する側のクラスの線の端に記述する事で表現する。
集約とコンポジションの違い
すべてのコンポジションは、0..1か1の多重度でなければならない。集約されるインスタンスは、される対象が一つだけでなければおかしいからだ。対して、集約の場合は、これに限らない。
現実世界で全体-部分の関係の例を挙げるとすれば、例えば車に対するエンジンの例が挙げられる。エンジンENG01は車のモデルCM01の部分であり、集約の関係がベストと言える。エンジンとしては、ENG01は他の車のモデルに搭載することも可能だからだ。例えばCM02等。これはしばしば、「カタログ」関係と呼ばれる。
クラスレベルの関係
汎化・特化
KP-UML-Generalization-20060325.svg
汎化の関係とは、関係するクラスの一方（スーパークラス）がもう一方（サブクラス）に対してより一般的であると考えられることを表す。実際問題、これはサブクラスのインスタンスがスーパークラスのインスタンスでもあることを意味している（このタイプの汎化の例は「binomial nomenclature」に見られる：人間は猿のサブタイプであり、猿は哺乳動物のサブタイプであり以下略）。この関係は、'AはB'とすると最も簡単に理解できる（人間は哺乳動物、哺乳動物は動物）。
UMLでの視覚的な記述方法としては、スーパークラス側の線の端に白抜きの三角を描くことで表現する。
汎化・特化の関係は、継承または"is-a"の関係としても知られる。
汎化・特化の関係において、スーパータイプは"親"、"スーパークラス"、"基底クラス"、"規定タイプ"としても知られる。
汎化・特化の関係において、サブタイプは"子"、"サブクラス"、"派生クラス"、"派生タイプ"、"派生型"としても知られる。
特化の関係は、汎化の関係の逆である。つまり、サブタイプはスーパータイプを特化したものである。
この関係が生物学的な親/子の関係との類似を全く持っていない事に注意すること：これらの用語は非常に一般的だが、使用方法によっては紛らわしい場合がある。
汎化 - 特化の関係：
AはBの一種
例えば、"オークは木の一種"、"貨物自動車は車の一種"
実現
実現の関係とは、関係するクラスの一方（クライアント）がもう一方（サプライヤ）の振る舞いを実現していることを表す。（訳注：例えば、抽象クラスやインターフェイスのメソッドの内容をサブクラスで具体的に記述すること）実現は視覚的には、白抜きされた三角を先端に持つ破線で表現する。
一般的な関係
依存
定義されている要素間に、片方を変更すればもう片方に変更が生じる依存が存在する。この関係は、依存する側からされる側への破線矢印で表現する。幾つかの名前付けされた種類がある。依存はインスタンス間、クラス間、インスタンス-クラス間にあり得る。
多重度
関連の関係は、関連するクラスの一方がもう一方を参照していることを意味する。汎化の関係と対比して、'AはBを持っている'というフレーズで最も簡単に理解できる（母猫には子猫がいる、子猫には母猫がいる）。
UMLでは、関係にオブジェクトのロールを矢印で示唆して表現する。オプションとして、それらのエンティティのインスタンスの多重度を両端に記述することができる。多重度とは、その関連に参加するオブジェクトの数を示すものである。一般的な多重度は以下：
記述 インスタンス数
0..1 無しか一つ
1 確実に一つ
0..* または * ゼロ個以上
1..* 1個以上
この関係は、"has-a"の関係としても知られている。
関連項目
ドメインモデル
外部リンク
アクティビティ図
https://ja.wikipedia.org/wiki/%E3%82%A2%E3%82%AF%E3%83%86%E3%82%A3%E3%83%93%E3%83%86%E3%82%A3%E5%9B%B3
アクティビティ図
UMLの図
構造図
クラス図
コンポーネント図
複合構造図
配置図
オブジェクト図（英語版）
パッケージ図
プロフィール図（英語版）
振る舞い図
アクティビティ図
コミュニケーション図（英語版）
インタラクション図（英語版）
シーケンス図
ステートマシン図
タイミング図 (UML)（英語版）
ユースケース図
表 話 編 歴
アクティビティ図（アクティビティず）とはフローチャートに似た図で、いわゆるビジネスロジックにおける手続き的な流れやプログラムの制御フローを表すUMLの図である。
目次
1 概要
2 図の作成方法
3 図の要素
4 参考文献
概要
UML 2アクティビティ図
UML 1アクティビティ図
システムの流れを表すため、フローチャートのUML版という位置づけで決められた。UML 1.0のときに制定されUML2.0で大きく拡張された。
アクティビティ図では、プログラムでの処理以外にも、業務フローなどの記載も可能である（フローチャートでも業務フローなどの記載も可能である）。
昨今ではフローチャートからアクティビティ図への移行が進んでいる（そもそもフローチャートという図法自体が、UMLが誕生した機縁であるオブジェクト指向の流行以前の、構造化の流行の際には時代遅れとされたものであるし、UMLツール等が対応しているのが従来のフローチャートではなくアクティビティ図なので、アクティビティ図が使われるというだけである）。
図の作成方法
初期状態「●」と終了状態「◉」を記載し、その間に矢印で処理を記載し、必要に応じて分岐などを記載する。ステートマシン図などと異なり、主に書くのは処理であることに注意する必要がある。
アクティビティ図
UMLの図
構造図
クラス図
コンポーネント図
複合構造図
配置図
オブジェクト図（英語版）
パッケージ図
プロフィール図（英語版）
振る舞い図
アクティビティ図
コミュニケーション図（英語版）
インタラクション図（英語版）
シーケンス図
ステートマシン図
タイミング図 (UML)（英語版）
ユースケース図
表 話 編 歴
アクティビティ図（アクティビティず）とはフローチャートに似た図で、いわゆるビジネスロジックにおける手続き的な流れやプログラムの制御フローを表すUMLの図である。
目次
1 概要
2 図の作成方法
3 図の要素
4 参考文献
概要
UML 2アクティビティ図
UML 1アクティビティ図
システムの流れを表すため、フローチャートのUML版という位置づけで決められた。UML 1.0のときに制定されUML2.0で大きく拡張された。
アクティビティ図では、プログラムでの処理以外にも、業務フローなどの記載も可能である（フローチャートでも業務フローなどの記載も可能である）。
昨今ではフローチャートからアクティビティ図への移行が進んでいる（そもそもフローチャートという図法自体が、UMLが誕生した機縁であるオブジェクト指向の流行以前の、構造化の流行の際には時代遅れとされたものであるし、UMLツール等が対応しているのが従来のフローチャートではなくアクティビティ図なので、アクティビティ図が使われるというだけである）。
図の作成方法
初期状態「●」と終了状態「◉」を記載し、その間に矢印で処理を記載し、必要に応じて分岐などを記載する。ステートマシン図などと異なり、主に書くのは処理であることに注意する必要がある。
통합 모델링 언어
통합 모델링 언어
UML 다이어그램
UML은 소프트웨어 집약 시스템의 시각적 모델을 만들기 위한 도안 표기법을 포함한다.
목차
개요
통합 모델링 언어는 객체 지향 소프트웨어 집약 시스템을 개발할 때 산출물을 명세화, 시각화, 문서화할 때 사용한다.[1] UML은 아래와 같은 사항을 포함하여 시스템의 구조적 청사진을 시각화 하는 표준안을 제공한다:- 행위자 (UML)
- 비즈니스 프로세스
- (논리적) 부품 (UML)
- 행위 (UML)
- 프로그래밍 언어 구문
- 데이터베이스 스키마
- 재사용할 수 있는 소프트웨어 구성 요소[2]
UML 모델은 객체 관리 그룹이 지원하는 QVT와 같은 변환 언어 등을 이용해 다른 표현(예를 들면 자바)으로 자동적으로 변환된다. UML은 확장할 수 있으며 커스터마이제이션을 위한 메커니즘인 프로파일 (UML), 스테레오타입 (UML)을 제공한다. 프로파일을 이용한 확장의 의미는 UML 2.0에서 개선되었다.
역사
UML은 그래디 부치(Grady Booch), 제임스 럼버(James Rumbaugh), 이바 야콥슨(Ivar Jacobson)의 머리에서 태어났다. 최근 “쓰리 아미고(Three Amigos-3인방)”이라고 불리는 이 세 사람은 80년대 전반 부터 90년대 초반까지 객체지향 분석 설계 분야에서 각자의 영역에서 방법론을 연구해 왔었다. 그들이 발표한 방법론은 동일한 분야의 다른 경쟁자들보다 항상 탁월한 위치에 있었으며, 세 사람은 90년대 중반에 이르러 각자의 아이디어를 교환하기 시작하였고, 결국 각자의 방법을 하나로 모아 합치기에 이른다.1994년, 럼버는 부치가 세운 래셔널 소프트웨어(Rational Software Corporation)에 영입 되었고, 야콥슨은 그로부터 1년 후에 래셔널 사에 들어가게 된다.
나머지는 그들이 말하듯이, 역사(History)라고 말할 수 있다. UML의 초안(draft) 버전은 소프트웨어 업계를 뒤흔들기 시작했고, 그 결과로 돌아온 피드백은 바로 변경점에 반영되었다. “UML은 우리들의 전략에 딱 맞는다”라고 인식해 가는 회사가 늘어남에 따라 그 결과로 UML 컨소시엄도 발족하게 되었다. UML 컨소시엄의 멤버로는 디지털(DEC), 휴렛 팩커드(HP), 인텔리캅(Intellicorp), 마이크로소프트, 오라클, 텍사스 인스트루먼트(Texas Instruments), 래셔널 소프트웨어 등이 있었다. 1997년 UML 컨소시엄은 UML 버전 1.0을 만들어 내었고, 객체 관리 그룹(OMG:Object Management Group)이 표준 모델링 언어의 제안서를 내라는 요구에 맞추어 이것을 제출 하였다.
UML 컨소시엄은 계속 발전하였으며, OMG에 다시 상정된 UML 1.1d은 1997년 말에 표준 모델링 언어로 채택되었다. OMG는 UML의 관리 기법을 받아들여 1998년에 새로운 수정안을 발표하였다. UML은 소프트 웨어의 업계 명실 상부한 표준이 되었으며, 계속 수정 보완되고 있다. 버전 1.3과 1.4 그리고 1.5가 나와 있고, 이전 버전들, 즉 버전 1.X는 대부분의 모델 및 UML 모델링 책의 기본이 되었다.[3] 2005년 버전 2.0이 OMG에 의해 승인되었다.
UML 구성요소
소프트웨어 개발 방법론
소프트웨어 개발 방법론 문서를 참고하십시오.모델
모델은 이학 및 공학 분야에서 상당히 유용하게 쓰이는 개념으로서 가장 일반적인 의미로 말하면, "모델을 만든다"는 것은 잘 모르고 있는 것을 이해하는데 도움이 될 것으로 추측되는 어떤 것을 사용한다는 뜻이다. 어떤 분야에서는 이 모델의 일련의 수식(방정식)의 집합으로 정의되기도 하며, 다른 분야에서는 컴퓨터 시뮬레이션을 모델로 삼기도 한다.UML의 여러가지 그래픽 요소는 하나의 큰 그림, 즉 다이어그램을 그리는데 사용된다. UML은 언어이기 때문에, 이들 그래픽 요소들을 맞추는 데에는 규칙이 필요하다. 다이어그램의 목적은 시스템을 여러가지 시각에서 볼 수 있는 뷰(View)를 제공하는 것이며, 이러한 뷰의 집합을 모델(Model)이라고 한다. 시스템의 UML 모델은 건물을 짓는 건축가의 스케일 모델과도 비슷하다고 말할 수 있다. UML 모델은 시스템 자체의 “목적 행동”을 설명하는 언어이다. UML 모델은 시스템의 “구현 방법을 설명하는 수단”이 아니다.
클래스 다이어그램
대부분의 사물은 자기만의 속성과 일정한 행동 수단을 지니고 있다. 이러한 행동을 오퍼레이션(Operation)의 집합으로 생각할 수 있다. UML에서는 두단어 이상으로 이루어진 클래스 이름은 단어 사이의 공백을 없애고, 각 단어의 처음 문자를 모두 대문자로 한다(예:Wikipedia). 속성과 행동의 이름 또한 마찬가지이지만, 가장 앞 단어의 처음 문자는 소문자로 한다(예:edit()).
피드 구독하기:
글 (Atom)