참고 블로그 :
- Submit your assignment using the following file format:
LabNumber_StudentName_Student_ID.zip
Example: Lab8_Hongkildong_201620505.zip
- This zip file will contain two types of files, namely:
1) Report file with file format “Report_Lab number” (eg. report_8) to answer theory questions
2) Source code file that contains codes of classes to answer programming questions.
Objectives
1. Understanding the requirements of an application and learning how to write represent them by using UML (Unified Modeling Language) diagrams.
2. Learning basic object-oriented analysis and design methods.
3. Developing the ability to draw UML (unified Modeling Language) diagrams.
4. Developing the ability to interpret and modify a code based on existing requirement document
1. 응용 프로그램의 요구 사항을 이해하고 쓰는 방법을 배우는 것은 UML(Unified Modeling Language) 다이어그램을 사용하여 그것들을 나타낸다.
2. 기본 객체 지향 분석 및 설계 방법 학습
3. UML(Unified Modeling Language) 다이어그램 그리기 능력 개발
4. 기존 요구사항 문서에 기초한 코드 해석 및 수정 능력 개발
ATM Case Study, Part 1: Object-oriented-design using UML
· Unified Modeling Language (UML) to design and implement an Object oriented-application.
· Case study: design and implementation of an object-oriented automated teller machine software system.
· Six types of UML diagrams are used to graphically represent the design of an Object-oriented Program, namely:
a) Use Case Diagram
b) Class Diagram
c) State diagram
d) Activity Diagram
e) Communication Diagram
f) Sequence Diagram
· Read the PPT and the attached book chapter to get detailed information.
· 객체 지향 애플리케이션을 설계하고 구현하기 위한 UML(Unified Modeling Language)
· 사례연구 : 객체지향 자동화 현금자동입출금기 소프트웨어 시스템의 설계 및 구현
· 객체 지향 프로그램의 설계를 그래픽으로 나타내기 위해 6가지 유형의 UML 도표를 사용한다.
· PPT 및 첨부된 책장을 읽고 자세한 정보를 얻으십시오.
ATM Case Study, Part 2: Implementing an object-oriented design
· Incorporate inheritance into the design of the ATM.
· Incorporate polymorphism into the design of the ATM.
· Fully implement in Java the UML-based object-oriented design of the ATM software.
· Study a detailed code walkthrough of the ATM software system
· Read the PPT and the source code to get detailed information.
· ATM 설계에 상속재산을 구체화 하라
· ATM 디자인에 다형성 구체화 하라
· ATM 소프트웨어의 UML 기반 객체 지향 설계를 Java에서 완전하게 구현.
· ATM 소프트웨어 시스템의 세부 코드 검토
· PPT 및 소스 코드를 읽고 자세한 정보를 얻으십시오.
Instruction
· For each of the following questions, write the answers directly in your report.
· If you draw a UML diagram by hand, take a picture and include it in this report.
· Please zip the code of question #4 into a file that has name: "ATMextended”. This question is optional
· 다음 각 질문에 대한 답은 보고서에 직접 작성한다.
· UML 도표를 손으로 그리면 사진을 찍어 이 보고서에 포함시킨다.
· 질문 코드 #4를 "ATMextended"라는 이름의 파일로 압축하십시오. 이 문제는 선택 사항이다.
Part 4. Exercises (15 points)
1. Analyze the “use case” scenario of Authenticate and Withdrawal, and then write the “use case” scenario for Transfer (5 points)
2. Analyze the “activity diagram” of Withdrawal, and write the “activity diagram” for Transfer. (5 points)
3. Write the “sequence diagram” for Transfer. (5 points)
4. Add the code for “Transfer” at the end of the given code(Optional)
Note: In order to answer the above questions, read the PPT and the given code.
1. Authenticate(인증하는것) 와 Withdrawal(취소) 의 "use case" 를 분석하고, Transfer(전송)의 "use case"를 작성하라.
www.m.blog.naver.com/ljh0326s/221001892737
2. Withdrawal의 "activity diagram"을 분석하고, Transfer를 위한 "activity diagram"을 작성하라.
3. Transfer를 위한 "sequence diagram"을 작성하라.
Part 1
요구사항 문서에는 ATM 시스템의 목적과 그 시스템이 무엇을 해야 하는지가 명시되어 있다.
한 국내 은행이 사용자(예: 은행 고객)가 기본적인 금융 거래를 수행할 수 있도록 새로운 현금 자동 입출금기(ATM)를 설치할 예정이다.
각 사용자는 은행에 하나의 계정만 가질 수 있다.
- ATM 사용자
그들의 계좌 잔액을 조회하다.
현금을 인출하다
자금을 예치하다
ATM 사용자 인터페이스
- 사용자에게 메시지를 표시하는 화면
- 사용자로부터 숫자 입력을 받는 키패드
- 사용자에게 현금을 지급하고
- 사용자로부터 예금 봉투를 받는 예금 슬롯
- 현금지급기는 매일 500달러 20센트짜리 지폐를 싣고 시작한다.
은행 고객이 ATM을 통해 시작한 금융 거래를 수행할 수 있는 소프트웨어를 개발하십시오.
컴퓨터의 모니터를 사용하여 ATM 화면을 시뮬레이션하고 컴퓨터의 키보드를 사용하여 ATM의 키패드 시뮬레이션.
ATM 세션은 다음과 같이 구성된다.
- 계정 번호 및 개인 식별 번호(PIN)를 기준으로 사용자 인증
- 금융 거래 생성 및 실행
사용자를 인증하고 트랜잭션을 수행하려면 다음과 같이 하십시오.
은행의 계정 정보 데이터베이스와 상호 작용하다.
각 계정에 대해 데이터베이스는 계좌 번호, PIN, 잔액을 계좌에 저장한다.
가정 간소화:
은행에서는 ATM을 한 대만 구축할 계획이므로 여러 대의 ATM이 동시에 이 데이터베이스에 액세스하는 것은 걱정할 필요가 없다.
은행은 사용자가 ATM에 접속하는 동안 데이터베이스 정보를 변경하지 않는다.
은행은 중요한 보안 조치 없이 ATM이 데이터베이스에 있는 정보에 접근하고 조작할 것을 신뢰한다.
ATM에 처음 접근할 때 사용자는 다음과 같은 일련의 사건을 경험해야 한다(그림 12.1 참조).
화면에 시작!이 표시되고 사용자에게 계정 번호를 입력하라는 메시지가 표시된다.
사용자는 키패드를 사용하여 5자리 계정 번호를 입력한다.
화면에는 사용자에게 지정된 계정 번호와 관련된 PIN(개인 식별 번호)을 입력하라는 메시지가 표시된다.
사용자는 키패드를 사용하여 5자리 PIN을 입력한다.
사용자가 유효한 계정 번호와 해당 계정에 대한 올바른 PIN을 입력하면 메인 메뉴가 화면에 표시된다(그림 12.2). 사용자가 잘못된 계정 번호나 잘못된 PIN을 입력하면 화면에 적절한 메시지가 표시되면 ATM이 1단계로 돌아가 인증 프로세스를 다시 시작하십시오.
사용자가 잔액조회를 하기 위해 1을 입력하면 화면에 사용자의 계좌 잔액이 표시된다.
그러기 위해서는 ATM이 은행의 데이터베이스에서 잔금을 회수해야 한다.
다음 단계는 사용자가 철회를 위해 2를 입력할 때 발생하는 상황을 설명한다.
화면에는 표준 인출 금액의 메뉴와 거래 취소 옵션이 표시된다.
사용자가 키패드를 사용하여 메뉴 선택을 시작한다.
뽑는 금액이 사용자의 계좌잔액보다 크면 이를 기재하고 더 적은 금액을 선택하라는 메시지가 화면에 뜬다. 현금 자동 인출기는 1단계로 돌아간다. 선택한 인출금액이 사용자의 계좌잔액(즉, 허용금액)보다 적거나 같으면, ATM은 4단계로 진행된다. 사용자가 취소를 선택하면 ATM이 메인 메뉴를 표시하고 사용자 입력을 기다린다.
현금지급기에 현금이 충분하다면, 현금자동입출금기는 5단계로 진행된다.
그렇지 않으면, 화면에는 문제를 나타내는 메시지가 표시되고 사용자에게 더 적은 인출 금액을 선택하라고 지시한다.
현금 자동 인출기는 1단계로 돌아간다.
ATM은 은행 데이터베이스에 있는 사용자 계정에서 인출 금액을 인출한다.
현금지급기는 사용자에게 원하는 금액을 지급한다.
화면에는 사용자에게 돈을 받으라는 메시지를 표시한다.
다음 단계는 사용자가 입금하기 위해 3을 입력할 때 발생하는 조치를 설명한다.
화면에는 입금 금액을 입력하거나 0을 입력해 취소하라는 메시지가 뜬다.
사용자는 키패드를 사용하여 예금 금액 또는 0을 입력한다.
사용자가 입금액을 지정하면 ATM은 4단계로 진행된다. 사용자가 (0을 입력하여) 거래를 취소하도록 선택하면 ATM이 메인 메뉴를 표시하고 사용자 입력을 기다린다.
화면에는 사용자에게 예금 봉투를 넣으라는 메시지가 표시된다.
입금 슬롯이 2분 이내에 입금 봉투를 받으면 ATM은 입금액을 은행 데이터베이스에 있는 사용자 계좌로 입금액을 크레디트(예: 입금액을 사용자의 계좌 잔액에 추가)한다.
시스템이 성공적으로 트랜잭션을 실행한 후에는 사용자가 추가 트랜잭션을 수행할 수 있도록 메인 메뉴로 돌아가야 한다.
사용자가 시스템을 종료하면 화면에 감사 메시지가 표시되고 다음 사용자의 환영 메시지가 표시되어야 한다.
ATM 시스템 분석
앞의 문장은 요구사항 문서의 단순화된 예다.
- 일반적으로 요구사항 수집의 세부 프로세스 결과
시스템 분석가는 소프트웨어가 무엇을 해야 하는지 더 잘 이해하기 위해 은행 전문가들을 인터뷰할 수 있다.
시스템 분석가는 획득한 정보를 사용하여 시스템 설계자가 시스템을 설계할 때 안내하는 시스템 요구사항 목록을 작성할 수 있다.
분석 단계는 해결해야 할 문제를 정의하는 데 초점을 맞춘다.
어떤 시스템을 설계할 때는 문제를 바로 해결해야 하지만, 똑같이 중요한 것은 올바른 문제를 해결해야 한다는 것이다.
분석 단계에서 시스템 설계자는 시스템이 무엇을 해야 하는지를 설명하는 높은 수준의 사양을 만들기 위해 요건 문서를 이해하는 데 초점을 맞춘다.
설계 단계(설계 규격)의 산출물은 이러한 요건을 충족하기 위해 시스템을 구성하는 방법을 명확히 지정해야 한다.
UML 2 표준은 시스템 모델을 문서화하기 위한 13가지 다이어그램 유형을 지정한다.
각 도표는 시스템 구조 또는 동작의 고유한 특성을 모델링한다. 즉, 6개의 도표는 시스템 구조와 관련되며, 나머지 7개는 시스템 동작과 관련이 있다.
우리는 클래스를 모델로 하는 클래스 다이어그램이나 시스템에서 사용되는 "빌딩 블록"만 사용할 것이다.
요구사항 문서에 나타나는 명사와 명사 구문을 분석하여 시스템 구축에 필요한 클래스를 파악한다.
우리는 이러한 명사와 명사 구절들 중 일부는 실제로 시스템에 있는 다른 계급의 속성이라고 결정할 수도 있다.
우리는 또한 명사들 중 일부는 시스템의 일부분에 해당하지 않으므로 모델화해서는 안 된다고 결론지을 수도 있다.
우리가 디자인 과정을 진행함에 따라 추가적인 수업들이 우리에게 명백해질 수 있다.
Goal
클래스 다이어그램을 이해할 수 있다.
클래스 다이어그램을 작성할 수 있다..
[들어가기 전]
UML (Unified Modeling Language) 이란
- 시스템을 모델로 표현해주는 대표적인 모델링 언어
UML 다이어그램의 종류
1. 구조 다이어그램 (Structure Diagram)
- 클래스 다이어그램 (Class Diagram)
- 객체 다이어그램
- 복합체 구조 다이어그램
- 배치 다이어그램
- 컴포넌트 다이어그램
- 패키지 다이어그램
2. 행위 다이어그램 (Behavior Diagram)
- 활동 다이어그램 (Activity Diagram)
- 상태 머신 다이어그램 (State Diagram)
- 유즈 케이스 다이어그램 (Use Case Diagram)
3. UML 작성 도구
UMLet - Free UML Tools for fast UML diagrams
UMLet is a free, open-source UML tool with a simple user interface: draw UML diagrams fast, build sequence and activity diagrams from plain text, export diagrams to eps, pdf, jpg, svg, and clipboard, share diagrams using Eclipse, and create new, custom UML
www.umlet.com
클래스 다이어그램 이란
시간에 따라 변하지 않는 시스템의 정적인 면을 보여주는 대표적인 UML 구조 다이어그램
- 목적 : 시스템을 구성하는 클래스들 사이의 관계를 표현한다.
클래스
클래스란
(1) 동일한 속성과 행위를 수행하는 객체의 집합
(2) 객체를 생성하는 설계도
- 즉 클래스는 공통의 속성과 책임을 갖는 객체들의 집합이자 실제 객체를 생성하는 설계도이다.
클래스는 "변화의 기본 단위"
디자인 패턴을 제대로 이해하려면 만들어진 프로그램을 흔들어보고 어떤 것이 변화되는지를 잘 살펴 봐야 한다.
UML 클래스의 표현
- 가장 윗부분 : 클래스 이름
- 중간 부분 : 속성(클래스의 특징)
- 마지막 부분 : 연산 (클래스가 수행하는 책임)
- 경우에 따라 속성 부분과 연산 부분은 생략할 수 있다.
- 속성과 연산의 가시화를 정의
>> UML 에서는 접근제어자를 사용해 나타낸다.
- 분석 단계와 설계 단계에서의 클래스 다이어그램
관계
UML에서 제공하는 클래스들 사이의 관계
1. 연관 관계
한 클래스가 다른 클래스와 연관 관계를 가지면 각 클래스의 객체는 해당 연관 관계에서 어떤 역할을 수행하게 된다.
- 두 클래스 사이의 연관 관계가 명확한 경우에는 연관 관계 이름을 사용하지 않아도 된다.
- 역할 이름은 실제로 프로그램을 구현할 때 연관된 클래스 객체들이 서로 참조할 수 있는 속성의 이름으로 활용할 수 있다.
- 연관 관계는 방향성을 가질 수 있다. 양방향은 실선으로, 단방향은 화살표로 표시한다.
화살표
단방향 연관 관계
- 한쪽은 알지만 다른 쪽은 상대방의 존재를 모른다.
실선
양방향 연관 관계
- 두 클래스의 객체들이 서로의 존재를 인식한다.
- 일반적으로 다대다 연관 관계는 양방향 연관 관계로 표현되는 것이 적절하다.
- 하지만 양방향 연관관계를 구현하는 것은 복잡하기 때문에 보통 일대다 단방향 연관관계로 변환해 구현한다 -> 연관 클래스
연관 클래스
연관 관계에 추가할 속성이나 행위가 있을 때 사용
연관 클래스를 일반 클래스로 변환
- 연관 클래스는 연관 관계가 있는 두 클래스 사이에 위치하며, 점선을 사용해 연결한다.
- 이 연관 클래스를 일반 클래스로 변환하여 다대다에서 일대다 연관 관계로 변환한다.
다중성 표시 방법
선에 아무런 숫자가 없으면 일대일 관계
2. 일반화 관계
한 클래스가 다른 클래스를 포함하는 상위 개념일 때 두 클래스 사이에는 일반화 관계가 존재한다.
- 객체지향 개념에서는 일반화 관계를 상속 관계 라고 한다.
부모 클래스
- 추상적인 개념
- 삼각형 표시가 있는 쪽
- 가전 제품
자식 클래스
- 구체적인 개념
- 삼각형 표시가 없는 쪽
- 세탁가, TV, 식기세척기
부모 클래스는 자식 클래스의 공통 속성이나 연산을 제공하는 틀이다.
예를 들어 가전 제품 클래스에 제조번호, 제조년도 같은 공통특성과 tunON tunOFF 같은 공통 연산을 자식 클래스에서 사용하면 된다.
추상 클래스
- 추상 메서드를 하나 이상 가지는 클래스
- 추상 메서드
>> 부모 클래스에서 구현되지 않은 빈 껍데기만 있는 연산
>> 예를들어 turnON과 turnOFF는 자식 클래스마다 다르기 때문에 부모 클래스인 가전 제품에서 해당 연산에 대한 정의를 하지 않고 빈
껍데기만 있는 연산(추상 메서드)을 제공한다
- 추상 클래스는 다른 일반적인 클래스와는 달리 객체를 생성할 수 없다.
- UML 에서의 추상 클래스와 추상 메서드 표현
>> 스테레오 타입 ('<<', '>>' 기호 안에 원하는 이름을 넣음)
3. 집합 관계
UML 연관 관계의 특별 경우로 전체와 부분의 관계를 명확하게 명시하고자 할 때 사용한다.
집약 관계 (aggregation)
- 한 객체가 다른 객체를 포함하는 것
>> '부분' 을 나타내는 객체를 다른 객체와 공유할 수 있다.
- '전체'를 가리키는 클래스 방향에 빈 마름모로 표시
- 전체 객체의 라이프타임과 부분 객체의 라이프 타임은 독립적이다.
>> 전체 객체가 메모리에서 사라진다 해도 부분 객체는 사라지지 않는다.
- 예시
>> 생성자에서 참조값을 인자로 받아 필드를 세팅한다.
합성 관계 (composition)
- 부분 객체가 전체 객체에 속하는 관계
>> '부분'을 나타내는 객체를 다른 객체와 공유할 수 없다.
- '전체'를 가리키는 클래스 방향에 채워진 마름모로 표시
- 전체 객체의 라이프타임과 부분 객체의 라이프 타임은 의존적이다.
>> 전체 객체가 없어지면 부분 객체도 없어진다.
- 예시
>> 생성자 필드에 대한 객체를 생성한다.
의존 관계
일반적으로 한 클래스가 다른 클래스를 사용하는 경우
- 클래스의 속성("멤버 변수")에서 참조할 때
- 연산의 "인자"(참조값)로 사용될 때
- 메서드 내부의 "지역 개체"로 참조될 때
연관 관계와 의존 관계의 차이
5. 인터페이스와 실체화 관계
인터페이스란
- 책임이다.
- 어떤 객체의 책임이란 객체가 해야하는 일 또는 객체가 할 수 있는 일
- 즉, 객체가 외부에 제공하는 서비스나 기능은 객체가 수행하는 책임으로 본다.
- 어떤 공통되는 능력이 있는 것들을 대표하는 관점
UML에서의 인터페이스 표현
- 인터페이스 : 클래스에 사용하는 사각형을 그대로 사용하고 인터페이스 이름 위에 <<interface>> 라고 표시
- 인터페이스 관계 : 빈 삼각형과 점선을 사용
객체지향 개념에서는 실체화 관계를 "can do this" 관계라 한다.
'📌 java > Object-oriented Programming' 카테고리의 다른 글
| ATM_Design (0) | 2020.05.09 |
|---|---|
| java - UML (0) | 2020.05.07 |
| Homework_W7 (상속 ≠ 오버라이딩) (0) | 2020.05.02 |
| java - 업캐스팅 다운캐스팅 (0) | 2020.04.26 |
| java - 상속의 참조 관계 (0) | 2020.04.26 |