소프트웨어공학에서 중요한 모델링과 모델링을 표현하는 도구인 UML에 대해 톺아본다.
모델링이란 요구사항에서 발생한 도메인을 체계화하는 과정으로 중요한 개념과 특성, 개념들 사이의 관계를 파악해 다이어 그램으로 정형화 하는 것이다.
모델링 과정은
도메인 분석 -> 도메인 개념정의 -> 모델링
순으로 진행된다.
그렇다면 모델링은 왜 필요하고 소프트웨어 개발 시 사용되는 이유가 무엇일까?
사람마다 하나의 내용을 보고 이해하는 게 다르다.
그렇게 위해선 서로 잘 이해했는지 검증하는 과정도 필요하고, 많은 의사소통이 동반 되기 때문에 시스템을 가시화 하고, 해석의 타당성을 검토하기 위해 소프트웨어 모델링 기법이 필요하다.
모델링 또한 표현하는 방법이 다양한데, 그중에 UML로 모델링을 하는 방법을 정리한다.
대표적인 시스템 모델링 언어이다.
UML의 종류로는 큰 범주 안에서는 구조다이어그램, 행위다이어그램이 있다.
클래스 다이어그램은 구조 다이어그램에 속하는 다이어그램이다.
시스템을 구성하는 클래스 간의 관계를 표현하기 위해 사용된다.
클래스는 속성과, 행위를 수행하는 객체의 집합이며, 변화의 기본단위이다.
가장 위부분은 클래스 이름으로 표현하고, 중간 부분은 속성, 마지막 부분은 연산으로 표현한다.
속성과 연산부분은 상황에 따라 생략이 가능하다.
속성과 오퍼레이션의 가시화를 정의하기 위해 사용한다
접근제어자 | 표시 | 설명 |
---|---|---|
public | + | 모든 클래스에서 접근 가능 |
protected | # | 클래스와 상속관계에 있는 하위클래스에서 접근 가능 |
package | ~ | 동일 패키지 내에서만 접근 가능 |
private | - | 해당 클래스 내에서만 접근 가능 |
속성은 [접근제어자] 이름 : 속성타입[다중성 정보][=초기값]
연산은 [접근제어자] 이름(인자1:타입1...) : 반환타입
접근제어자를 사용하여 속성과 연산을 위와 같이 표현할 수 있다.
또한, 정적연산(static)의 경우에는 연산에 underline을 표시한다
ex. -연락처검색():String
클래스 다이어그램에서 분석단계에서 표현하는 것과 설계 단계에서 표현하는 다르다.
주로 분석단계에서는 속성, 연산만 추상적으로 표현하는 반면, 설계단계에서는 객체의 접근제어자와 반환형 까지 구체적으로 표현한다.
UML에서 제공하는 클래스 사이의 관계이다.
관계의 종류로는 연관관계, 일반화관계, 집합관계, 의존관계, 실체화관계가 있다.
클래스들이 개념상 연결 되어 있는걸 나타내는 관계이다.
두 클래스 사이의 연관관계가 명확한 경우에는 이름을 사용하지 않아도 되며, 역할 이름은 연관된 클래스의 객체들이 서로를 참조할 수 있는 속성의 이름으로 사용한다.
또한, 연관관계는 방향성을 가진다.
클래스를 연결한 선에 실선만 사용해서 표시한다. 또한 두 클래스가 서로의 존재를 인식한다.
코드
public Person { private Car[] Cars; }
public Car { private Person Owner; }
두 클래스를 연결할때 화살표로 표시한다. 한쪽으로만 방향성이 있어 다른 한쪽은 알지만 다른쪽은 상대방이 모른다.
코드
public Person { private Car[] Cars; }
public Car { }
화살표가 Car 쪽으로 표시되어 있기때문에 Car클래스에는 Person 클래스를 참조하는 속성이 없다.
다중성 | 의미 |
---|---|
1 | 엄밀하게 1 |
or 0.. | 0 또는 그 이상 |
1..* | 1 이상 |
0..1 | 0 또는 1 |
1,2,3 | 1 또는 2 또는 3 |
1,3..5 | 1 또는 3 또는 4또는 5 |
두 클래스가 상속관계일 때 두 클래스 사이에는 일반화 관계가 존재한다.
객체지향 개념에서는 일반화 관계를 is a kind of 관계 라고 한다.
부모클래스는 추상적인 개념을 표현하고 자식클래스의 공통연산 등을 제공, 자식클래스는 구체적인 개념을 포함한다.
uml에서 추상클래스는 스테리오타입(<< >>) 를 이용해서 표현한다.
ex. << abstract >> 클래스명
전체와 부분간의 관계를 의미한다.
한 객체가 다른 객체를 포함하는 하는 관계이다.
표현 방법은 빈마름모 화살표로 표현 한다.
전체 객체의 라이프타임과 부분객체의 라이프 타임은 독립적이기 때문에 전체 객체가 메모리에서 사라져도 부분 객체는 메모리에 존재한다.
인스턴스가 인자로 전달된다.
public class Computer {
private MainBoard mb;
private CPU c;
public Computer(MainBoard mb,Cpu c){
this.mb = mb;
this.c = c;
}
}
부분 객체가 전체 객체에 속하는 관계이다.
표현 방법은 전체를 가리키는 클래스 방향에 채워진 마름모로 표시하는 것이다.
또한, 전체를 나타내는 객체에 부분을 나타내는 개체의 라이프타임이 종속적이기 때문에 전체객체가 사라지면 부분 객체도 사라진다.
생성자를 통해 인스턴스를 생성한다.
public class Computer {
private MainBoard mb;
private CPU c;
public Computer(){
this.mb = new MainBoard();
this.c = new CPU();
}
}
클래스의 속성으로 참조할 때 연산자의 인자로 사용될 때 같이 한 클래스에서 다른 클래스를 사용하는 경우를 의존관계라고 한다.
표현방법은 점선으로 나타낸다.
연관관계도 다른 클래스를 사용한다는 점에서 의존관계와 비슷하다고 혼동을 할 수 있다.
연관관계는 지속적인 관계. 즉, 객체가 생성되고 나서도 라이프타임이 살아있는 관계이다.
보통 클래스의 속성에서 참조하는 경우 연관관계를 맺고 있다고 한다.
ex.
public class Person{
private Car owns;
public void setCar(Car car){
this.owns = car;
}
public Car getCar(){
return this.owns;
}
의존관계는 찰나적관계이다. 보통 연산의 인자나 메소드의 지역개체로 참조하는 경우 의존관계를 갖고있다고 한다.
ex.
public class Car{
...
public void fillGas(GasPump p){
p.getGas(amount);
}
}
실체화 관계에서는 인터페이스를 책임으로 본다. 즉, 공통되는 능력이 있는 것들을 대표하는 관점으로 생각한다.
표현은 빈 삼각형과 점선을 사용해 표현한다.
객체지향 개념에서 실체화관계를 can do this 관계 라고 한다.
또한, 서비스를 제공하는 클래스가 변경되어도 그 서비스를 사용하는 클라이언트 쪽 코드는 영향을 주지 않는다.
자바 객체지향 디자인 패턴 : UML과 GoF 디자인 패턴 핵심 10가지로 배우는