3주차 목요일
학교다닐적에 소프트웨어 공학에서 고객의 요구사항에 대해 유스케이스 다이어그램을 그렸던 기억이 났다. 개발자가 알아보기 쉽게 도식화하여서 동기들과 과제할 때 사용자, 인터페이스, 기능등을 이해하고 협업했던 기억이 있다. 다시보니 반갑다. 엑터와 유스케이스간의 관계, 유스케이스간의 관계를 배웠다. 추상화 클래스, 추상화메소드, 인터페이스를 배웠다. 양이좀많다.
배운점
변화하는 것을 알아야 오래 일할 수 있다.
cs 모르면 안됨
Usecase 다이어그램
도식화하고 스콥을 정하고 스콥에 맞춰서 협업할 수있도록 표준화시키는 방법론
도식화해서 표준화 시키는 방법: UML 언어
기능적인 부분을 유즈케이스로 표현한다. 개발자들은 코드로 구현한다.
유스케이스 다이어그램의 필요성
요구 사항 정의는 개발과 설계에서 매우 큰 비중을 차지함
누가who 시스템을 사용할 것인가? 중요!
시스템은 사용자를 위해 무엇what을 해야 하는가? 누가 디테일하게 정의하냐에 따라 퀄리티가 다름
사용자와 상호작용하기 위해 시스템이 제공해야 할 인터페이스interface는 무엇인가?
인터페이스: 화면, 버튼, 검색창 , 등등.. 기능과 연관되어 있다.
해당기능을 수행하는 것
검색창: 검색기능을 제공, 사용자와 상호작용위한 것
네모박스 : 시스템
유즈케이스 1,2,3: 기능 정의
외부: 사용자들
액터:
사용자에 따라 기능들이 정해진다.
개발할 시스템 외부의 존재, 이밴트 흐름을 시작하게 하는 객체, 동작시키는 사람
유즈케이스:
시스템 내부에 해당되는 단위 기능, 사용자 관점에서 시스템을 모델링
function, 사용자들 관점에서 기능적인 부분을 정의한다.
일반적인 연관 관계 외에 다양한 관계가 존재할 수 있음
엑터, 유스케이스
액터-액터 , 유스케이스-유스케이스
-유스케이스 사이의 포함Include 관계:
다른 유스케이스에서 기존 유스케이스를 재사용할 수 있음을 나타냄
예제 OrderLine은 Order에의해 기능이 불려서 사용됨
-유스케이스 사이의 확장Extend 관계:
기존 유스케이스에 진행 단계를 추가하여 새로운 유스케이스를 만들어내는 관계
-액터 사이의 일반화 관계:
일반화 관계: 상속
연관Association 관계
액터-유스케이스
해당 액터와 정보를 주고받는 유스케이스와 설정함
―로 표시
1.신용카드 결제(유스케이스)가 카드 승인시스템과 연결 되었다.
2. 액터: 사용자, 관리자(실선 - 연관관계)
유스케이스: 상품 선택, 상품주문, 물품관리
사용자는 상품선택, 상품 주문과 관계가 있고
관리자는 물풀관리와 관계가 있다.
유스케이스 사이의 관계
포함 관계
하나의 유스케이스를 수행할 때, 같은 기능이 있는 다른 유스케이스가 반드시 수행되는 관계
액션이 이루어져야 다음 스탭이 진행될 수 있다.
흐름 간계가 필요함
(a)에서 고객이 자판기에 동전을 투입하면 금액이
자동으로 표시 된다
(b)에서는 사서가 이용자 확인과 도서 번호 입력을
거쳐 대출하고, 반납 시 도서 번호 입력만 한다
(c)에서는 입출고 담당자가 신제품 입고나 상품 출고를
하면 자동으로 현황 등록이 이루어진다
흐름!!
여러 유스케이스에 공통적인 기능을 표현하기 위해 사용된다.
포함 유스케이스로 분기되는 이벤트 흐름이 필수적이다.
기준 유스케이스 이후의 이벤트 흐름이 포함 유스케이스의 수행결과에 의존한다.
- 기준 유스케이스인 결제에 기술된 이벤트 흐름이 차례로 수행
- 확장 부분에서 확장 유스케이스인 신용카드 결제나 포인트 결제로 분기
- 확장 유스케이스에 기술된 이벤트 흐름의 수행이 완료
- 다시 기준 유스케이스로 되돌아와서 이후의 이벤트 흐름을 수행
확장 관계
확장하는 유스케이스는 상위 유스케이스로부터 어떠한 특정 조건에 의해 수행
기본 유스케이스를 수정하지 않고 새로운 요구 사항을 추가로 표현하고자 할 때 사용
메일 도착했는데 확인은 선택적이다.
버스를 예매하고 표를 확인한다. 필수가 아님!!
카드선택, 포인트결제, 앱카드 다 선택적이다.
a)는 KTX를 예약한 후 결과를 확인하거나 확인하지
않을 수 있는 예다
(b)는 메일이 도착했으나 확인은 선택이다
(c)는 결제할 때 신용카드 또는 포인트 로 결제하는
경우이다
(d)는 영화를 현장에서 예매하거나 모바일로
예매하는 경우이다
기준 유스케이스에 부가적으로 추가된 기능을 표현하기 위해 사용된다.
기준 유스케이스에 기술된 조건에 따라 분기가 선택적으로 수행된다.
기준 유스케이스 이후의 이벤트 흐름이 확장 유스케이스의 결과에 의존하지 않는다.
- 기준 유스케이스인 동전 투입에 기술된 이벤트 흐름이 차례로 수행
- 특정 지점에서 포함된 유스케이스(금액 표시)로 바로 분기
- 금액 표시 유스케이스의 이벤트 흐름이 모두 수행되면 다시 동전 투입
- 유스케이스의 이벤트 흐름으로 돌아와 이후의 이벤트를 수행
액터 사이의 관계
일반화 관계
액터들이 유스케이스와 중복하여 관계가 나타나면 액터들을 통합하여 일반화 관계로 표현
추상적인 액터와 좀 더 구체적인 액터 사이에 관계를 맺어줌
고객은 회원 또는 비회원의 일종이다.
고객은 회원이나 비회원에 해당된다.
중복 관계
유스케이스 모델링을 할 때 유스케이스 이벤트 흐름에서 중복된 부분이 있을 때 설정
중복되는부분 남발하지않기위해 이런 이벤트 흐름이 필요하다. 업무 프로세스.
플로우
사용자 요구 확인 -> 업무프로세스플로우-> 중복되는거 묶음 -> 유스케이스 클래스 다이어그램 순서 ..
1단계 : 시스템 상황 분석
2단계 : 액터 식별
3단계 : 유스케이스 식별
4단계 : 유스케이스 다이어그램 작성
5단계 : 유스케이스 명세서 작성
6단계 : 유스케이스 실체화
추상화
불필요한 정보를 숨기고 중요한 정보만을 나타내는 것을 의미
어떤 영역에서 필요한 공통의 속성이나 행동을 추출함으로써 효율적인 코드를 작성할 수 있음
차의 공통 기능 : accelerate(), brake(), steer()
추상화 사용의 장점
객체 간의 복잡성이 줄어듦
코드의 중복을 막고 재사용성을 높일 수 있음
사용자에게 중요한 세부 정보만 제공하므로 응용 프로그램이나 프로그램의 보안에 도움이 됨
추상화 유형
데이터 추상화
주로 복잡한 자료형을 만들고 구현을 숨기는 것으로, 구현의 세부 사항으로 이동
하지 않고 데이터 유형을 조작하는 작업만 노출
데이터를 처리하는 과정만 보여 줄뿐 오픈하지 않는다.
제어 추상화
작업의 단위 정의를 만들고 필요할 때마다 재사용하는 것으로, 반복되는 모든 코
드 를 수집하고 이를 하나의 단위로 노출, 중복배제
오버로딩, 오버라이딩
추상화 구현 방법
추상 클래스, 인터페이스
추상 클래스 선언
추상 클래스는 abstract 키워드를 사용하여 선언
클래스 내에 일반 메서드뿐 만 아니라 추상 메서드를 포함할 수 있음
본문이 없는 메서드인 추상 메서드는 abstract 키워드를 사용하여 선언
바디가 없다.
추상 메서드는 자식 클래스에서 구현됨
입맛에 맞게 자식에서 정의해서 쓰렴
Dog 클래스 생성 후
main에서 Dog 생성함
Animal 추상클래스로 만들었다. 추상메소드도 하나 정의했다.
public abstract class Animal {
public abstract void printSound(); // 추상메소드
public void displayInfo(){ // 일반메소드
System.out.println("나는 동물입니다.");
}
}
Dog class
메소드 반드시 바디 만들어줘야한다.
public class Dog extends Animal{
@Override
public void printSound() { // 반드시해줘야한다
}
}
main
Animal 로 Dog객체 만듦. 외부에서는 얘가 뭔지 모름
public static void main(String[] args) {
Dog dog = new Dog();
dog.printSound();
Cat cat = new Cat();
cat.printSound();
Animal dog2 = new Dog();
dog2.printSound();
Animal d = new Dog(); // 외부에서는 얘가 dog인지 모름
Animal c = new Cat();
//인터페이스로 제어를 추상화하는방법 알아야함
}
주의 사항
추상 클래스는 항상 abstract 키워드를 사용하여 선언해야 함
추상 클래스의 모든 메서드를 추상으로 사용할 필요는 없음
추상 클래스에 일반적인 메서드가 포함될 수도 있음
클래스의 메서드 중 하나가 추상 메서드이면 해당 클래스는 추상 클래스여야 함
추상 메서드를 선언하면 자식 클래스에서 해당 메서드를 재정의해야 함
추상 클래스를 상속하는 경우 메서드 재정의는 필수
상속받은 클래스와 자식 클래스가 추상 클래스라면 메서드를 재정의하지 않아도 됨
현재 클래스가 상위 클래스처럼 추상적인 경우에는 상위 클래스의 메서드를 재정의할 필요없음
추상 클래스는 자신의 인스턴스를 가질 수 없음 // 힙에저장안함
추상적인 클래스의 객체를 가질 수 없으나 추상 클래스를 참조하는 객체는 가질 수 있음
프로그램이 자식 클래스의 객체를 만들 때 컴파일러가 추상 클래스의 생성자를
호출함
상속만 가능하고 객체를 생성할 수 없는 클래스를 생성하려면 추상 클래스 내부
에 일반 메서드만 가질 수 있음
단일 클래스가 여러 추상 클래스를 상속받을 수 없음. 다중 상속을 구현하려면
인터페이스를 사용해야 함
추상 클래스에 final() 메서드를 포함할 수도 있음
하지만 final 클래스는 추상 메서드를 가질 수 없음
public abstract class AbstractDog extends Animal{
public abstract void tailing();
}
추상클래스를 상속받은 추상클래스: 자식은 부모의 부모, 부모메소드 다 쓸 수있다
인터페이스
내가 원하는 인터페이스 다중 상속 가능
이는 부모 클래스가 메서드명만 가지고 있고 자식 클래스가 해당 메서드명을 사
용하여 필요에 따라 본문을 정의한다는 것을 의미
추상 클래스는 추상 메서드를 포함할 수도 있고 포함하지 않을 수도 있음
클래스에 추상 메서드가 포함되어 있으면 반드시 추상 클래스로 선언해야 함
추상 클래스와 마찬가지로 인터페이스는 그 자체의 객체를 만들 수 없음
추상 클래스는 추상 메서드와 일반 메서드를 포함할 수 있지만 인터페이스는 추상 메서드만 포함할 수 있음
사용 이유
완전한 추상화를 구현할 수 있음
다중 상속을 구현할 수 있음
느슨한 결합 관계를 형성할 수 있음 :뺐다꼈다 유연하게함
두 객체를 연결하는 역할
다형성 구현에 주된 기술
인터페이스는 interface 키워드를 사용하여 선언
인터페이스 내부에 있는 모든 메서드는 추상 메서드, 즉 본문이 없는 메서드임접근
제한자로는 클래스와 마찬가지로 같은 패키지 내에서만 사용 가능한 default,
패키지와 상관없이 사용하는 public을 붙일 수 있음
애초에 공용임, private 불가
RemoteControl class
public interface RemoteControl {
public void turnOn();
public void turnOff();
}
Television class
public class Television implements RemoteControl{
@Override
public void turnOn() {
System.out.println("TV전원 On");
}
@Override
public void turnOff() {
System.out.println("TV전원 Off");
}
}
Audio class
public class Audio implements RemoteControl{
@Override
public void turnOn() {
System.out.println("Audio on");
}
@Override
public void turnOff() {
System.out.println("Audio off");
}
}
Main class
인터페이스는 참조 타입에 속하므로 인터페이스 변수에는 객체를 참조하고 있지 않다는 뜻으로 null을 대입할 수 있음 :약한 객체 결합
인터페이스를 통해 구현 객체를 사용하려면, 인터페이스 변수에 구현 객체의 번지를 대입해야 함
RemoteControl로 만든 모든구현객체는 인터페이스로 담을 수 있다!
public static void main(String[] args) {
RemoteControl rc1;
RemoteControl rc2;
rc1 = new Television(); //interface rc에 객체생성
rc1.turnOn();
rc1.turnOff();
rc1 = new Audio(); // 같은 변수에 오디오 객체생성
rc1.turnOn();
rc1.turnOff();
}
회고
엑터와 유스케이스간의 관계, 유스케이스간의 관계를 개념적으로 확실히 익힐 수 있었다. 프로그램은 결국 사용자가 사용한다. 누가 사용할 것인지, 무엇을 해야하는지(기능들), 인터페이스는 뭔지 알아보기 쉽게 나타내는 것이 중요하다. 그래야 알아보기 쉽고, 협업도 편할 것이다.
평소 헷갈렸던 추상화클래스와, 인터페이스에대해 자세히 알게되었다. 학교다닐때 개념적으로만 외웠는데, 실제로 많은 예제를 직접 구현해보니 차이를 알 것 같다. 점점 객체지향에 대해 알아간다.
'신세게 - Java 공부' 카테고리의 다른 글
4주차 배운점 느낀점 - 인터페이스, 다형성, 타입변환 (7) | 2024.10.03 |
---|---|
3주차 배운점 느낀점 - 클래스 다이어그램, 클래스간의 관계 (9) | 2024.10.03 |
3주차 배운점, 느낀점 - 도메인, 모델, 요구사항 (10) | 2024.10.03 |
3주차 배운점 느낀점 - 상속, 부모, 자식, 단일, 다단계, 타입제한, 조별과제 (2) | 2024.09.26 |
3주차 배운점 느낀점 - 생성자, 오버로딩, this(), 접근제한자, 조별과제 (10) | 2024.09.24 |