[UML][국비교육] Day 55

Ga02·2023년 3월 20일
uml국비교육

국비교육

목록 보기
52/82

프로그램 개발 절차

기획 ➡ 설계 ➡ 구현

  • 기획
    • 요구사항 정리 👉🏻 요구 공학 : 소프트웨어 공학의 한 분야
    • 개발 기능 정의
    • 업무 프로세스 파악
    • 화면(UI) 기획 / 설계 / 구현
    • DB(데이터 구조) 기획 / 설계 / 구현 ➡ 전체적인 프로그램을 이해해야 잘 짤 수 있음
      게시판이 있었음 좋겠다~
  • 설계
    프로그램을 구체적으로 설계 👉🏻 개발 계획
    구현하기ㅣ 위해 클래스가 몇개가 필요하며(게시판 클래스, 메소드, FK PF 연결관계, 댓글 클래스 등등)
    프로그램의 컴포넌트 나누기➡ 우리같은 경우는 자바라서 클래스가 될 것
    (디자인 패턴, MVC 패턴구조, 메소드, 변수 등을 정의)
    서로 호출할 메소드 변수 클래스 등을 맞추기
  • 구현
    로직구현
    알고리즘 구현
    가독성 고려, 재사용성 높이기
    실 서버에 배포하기~
    잘 만들고 구현이 잘 되면 아마존 웹서버 배포하는게 좋음~
    에러 없이 잘 돌아가게 만드는걸 목표로 하자~

요구사항 정리
테이블이 어떤게 필요할까? 10개~20개 연결성을 고려해 같이해도 되고~
합치고 나누고 합치고 나누고 될 때까지 반복하기

모든걸 결과문서로 남기기 ➡ 이게 포트폴리오가 됨

🔍 UML, Unified Modeling Language

통합 모델링 언어(도구), 표준화된 모델링 언어

  • SW에 대한 구상(개발 방법)을 추상화하여 표현하는 방법들을 모은 것
  • 기획, 설계, 수현으로 이러지는 프로그램 개발과정의 중간 산출물들을 표현하는 방법을 표준화 해놓음 👉🏻 일종의 문서 작성법 / 최종적인 목표는 소프트웨어를 분석하기 쉽게, 파악하기 쉽게 만들기 위함
  • 프로젝트 참가자(이해관계자)들이 서로 원활하게 의사소통할 수 있도록 도와줌
    • 프로젝트 참가자 : 개발자, 기획자, UI 디자이너, 퍼블리셔, 엔지니어, 사장, 고객, 대표, 사용자, 테스터 등등

➰ 우리한테 필요한 중간 산출물

  • 화면 정의서 : 화면(UI) 구현을 위한 설계서
    스토리보드(StoryBoard)
    툴 : 카카오 오븐

  • 화면 요구사항 정의서
    사이트맵 : 웹페이지에 어떤 메뉴들이 있는데 1depth, 2depth에 뭐가 들어가지?
    상세 페이지 리스트 : 그 페이지 안에 들어갈 내용 / 회원가입이라면 회ㅜ언가입의 기능, 로그인이라면 로그인의 기능
    화면 설계(정적, 동적 구조 설명 포함) : 예상되는 화면 그리기 / 버튼을 어디에 둘건지 등

요구사항 : 소프트웨어에서 기능적, 비기능적 구현되어야 하는 사항들
요구사항 도출
어떤 요구사항이 필요한지 알아야~

요구사항 기술서 👉🏻 이번에는 생략~
책 p.57 참고~

  • 요구사항 정의서, 명세서
    기술서를 생략하고 바로 정의서 작성하기
    소프트웨어의 요구사항을 정리한 문서
    • 기능적 요구사항 : 구현해서 개발해야하는 사항들
    • 비기능적 요구사항 : 개발시 주의할 사항들
      정의서 : 요구사항들을 기능당 한 문장 수준으로 정리한 것(요약) 👉🏻 이건 잘 꼭 만들기 꼼꼼히
      명세서 : 요구사항 항목별로 자세히 설명을 포함하여 작성한 것(상세)
      툴 : 엑셀, 구글 스프레드시트

[게시판]

게시글 작성할 수 있다
게시글 작성시 첨부파일을 추가할 수 있다
첨부파일의 용량은 5MB로 제한한다

[메뉴]

사이트 전체의 메뉴를 2단계로 나눠서 표현한다
메뉴를 다국어 지원함
다국어는 영어, 일본어, 중국어로도 표현한다
음성 안내버튼을 누르면 메뉴를 음성으로 안내한다

  • 유스케이스 다이어그램
    사용자 입장에서 바라보는 소프트웨어의 기능들을 정의한 문서
    사용자와 기능 사이의 관계
    기능들 사이의 관계
    기능 중심으로 시스템을 한 눈에 파악할 수 있도록 작성
    소프트웨어를 사용하는(동작시키는) 행위자 : 액터, Actor
    행위자가 사용하는 기능 : 유스케이스, Usecase
    행위자와 기능 사이의 관계 : 관계, Relation,
    툴 : https://app.diagrams.net/
    StarUML 5.0 👉🏻 설치가 필요한 프로그램

계획에 가까운 기획단계에서 만들어지는 문서들

구현 전 설계에서 만들어지는 문서들

  • 클래스 다이어그램
    클래스의 구조를 정적으로 표현하는 그림

    • 클래스의 접근제한자, 멤버, 객체 간의 관계를 표현
    • 객체지향 프로그래밍에서 많이 활용됨 👉🏻 꼭 만들어야하고 필요함
    • StrarUML 5.0 / draw.io / Eclipse ObjectAid 플러그인

  • 시퀀스 다이어그램
    클래스 다이어그램 먼저 작성 후 시퀀스 다이어그램 작성
    프로그램이 실행될 때 객체(클래스)들의 동작을 표현한 그림
    멤버 메소드가 호출되면서 연결되는 객체(메소드)들의 흐름을 나타냄
    ❗ 구조를 전체적으로 파악하고 있는 사람이 만들어야 함
    해존적이 없으니 어려울 것. 여러번 다시 해봐야함~
    누가보든 따라할 수 있게 작성해야 좋음
    StatUML 5.0
    draw.io

class MemberLoginController {
	MemberSercer ms = new
    
    public void method() {
    	Object ret = ms.getLoginMember(req)
    }
    

}

public class MemberService {

	public Object getLoginMember(Http req) {	//입력데이터(ID PW) 전송
    	//코드 구현
        return data;	//입력데이터 변수 설정
    }

}

두 코드가 getLoginMember()로 이어짐

** 프로그램을 위한

  • ER 다이어그램, ERD
    데이터베이스를 설계한 그림
    테이블의 구조, 테이블들 간의 관계를 표현
    툴 : ERDCloud
    ** 데이터베이스를 위한

정적 다이어그램 : 구조를 표현하는 다이어그램
클래스 다이어그램

동적 다이어그램 : 행위, 동작을 표현하는 다이어그램
시퀀스 다이어그램
유스케이스 다이어그램

UML 도구

draw.io 사이트
'사용자 기기' 선택
새로운 다이어그램 만들기
'새 다이어그램' 선택
만들기 버튼
파일명 넣고 저장

파일 메뉴 - 내보내기 선택
이미지 파일 선택 - 다운로드

StrarUML 프로그램
New Project By Approach에서 Empty Project 선택
우측 Model Explorer에서 'untitled' 항목 우클릭
Add - Packcage 선택
패키지 항목에서 우클릭
Add Diagram - Use Case Diagram 선택
작업
File메뉴 - Export Diagram 선택

🔍 유스케이스 다이어그램, Usecase Diagram

액터, 유스케이스, 관계로 이루어져있음

➰ 액터, Actor

행위자
소프트웨어를 사용하는 입장을 도형으로 표현

  • 사용자 액터
    시스템(프로그램)의 기능을 요구하거나 실행하는 주체
    기능을 수행하고 그 결과를 통보(리턴)받는 사용자

  • 시스템 액터
    사용자 액터가 사용한 유스케이스를 처리해주는 외부의 시스템
    프로그램의 기능 수행을 위해 연결된 외부 프로그램
    카카오 우편번호 API

➰ 유스케이스, Use-Case

액터 입장에서 바라보는 프로그램의 기능
액터의 요청에 반응하여 정보를 가공하거나 서비스하는 기능적 단위 👉🏻 기능이 아니라면(비기능적 요구사항) 적지 않아도 됨

➰ 커뮤니케이션, Communication

  • 연관관계 : 기본적인 기능 수행 관계 / 액터 - 유스케이스
  • 일반화관계 : 상속관계 / 액터 - 액터, 유스케이스 - 유스케이스
  • 포함관계 : 기능적으로 필수 포함관계 / 글쓰기와 로그인(로그인을 해야만 글을 쓸 수 있는 경우) 유스케이스 - 유스케이스
  • 확장관계 : 선택적 관계 / 유스케이스 - 유스케이스

➰ 연관관계, Association

액터와 유스케이스의 상호작용

  • 액터가 사용하는 유스케이스(기능)과의 연결
  • 실선으로 표현

➰ 일반화 관계, Generalization

액터 - 액터 / 유스케이스 - 유스케이스 사이에서 사용됨

  • 일반화 대상과 추상화 대상의 연결
  • 유스케이스 다이어그램의 중복 표현을 줄이기 위해 사용됨 👉🏻 같은 유스케이스를 사용할 수 있는 액터들의 표현(관계)를 줄여줌
  • 액터끼리는 상속관계가 드러남
  • 유스케이스끼리는 추상화된 기능을 구체화된 기능으로 연결할 때 사용함
  • 실선에 투명한 세모머리 화살표로 표현
    추상화(부모)<----구체화(자식)

➰ 포함 관계, Include

유스케이스가 다른 유스케이스의 서비스(기능)을 요청함

  • 하나의 유스케이스(기능)가 서비스 될 때 또는 서비스 도중 다른 유스케이스를 반드시 사용해야할 때를 표현
  • 필수적으로 같이 포함되어 실행되어야하는 관계를 표현
  • 점선 위에 <<include>>라고 표시하며 > 머리화살표로 표현
  			<<include>>
  유스케이스1 - - - - - > 유스케이스2
➡ 유스케이스 1이 실행될 때 유스케이스2를 사용함(필수)

👀 Example
[고객은 로그인 할 수 있다]
** 아래 둘은 반드시 로그인을 해야 할 수 있음 👉🏻 include
-고객은 주문할 수 있다
-고객은 회원정보를 수정할 수 있다

고객은 주문을 하기 위해서 로그인을 해야 한다
고객은 회원정보 수정을 하기 위해 로그인을 해야 한다

➰ 확장관계, Extends

선택적으로 추가 수행할 수 있는 유스케이스를 표현

  • 포함관계는 반드시 수행하는 관계이지만 확장은 수행하지 않아도 됨 👉🏻 화면에 추가적인 기능 버튼이 있지만 누르지 않을 수도 있는 상황
  • 점선 위에 <<extends>>라고 표시하며 > 머리화살표로 표현
			<<extends>>
유스케이스1 < - - - - - - 유스케이스2
➡ 유스케이스1을 수행하면서 유스케이스2를 선택적으로 사용할 수 있음

👀 Example
회원은 게시글을 작성할 수 있다
게시글을 작성하면서 첨부파일 기능을 이용할 수 있다

➰ 유스케이스 다이어그램 작성 순서

요구사항 정의(명세)를 토대로 작업함
1. 액터 찾기
요구사항(기능적)을 수행하는 대상
프로그램에 정보를 제공하고, 사용하고, 삭제하는 대상으로 추출한다 ➡ CRUD를 수행하는 대상

2. 유스케이스 찾기
액터와 상호작용하는 기능
액터가 수행하려는 CRUD 작업
기능적 요구사항들을 유스케이스로 추출(도출)함

3. 관계 정의
연관 : 액터가 사용하는 유스케이스 연결
일반화 : 액터끼리, 유스케이스끼리 중복 표현 제거
포함 : 필수적으로 수행되는 기능 연결
확장 : 선택적으로 수행되는 기능 연결

profile
Ga02
IT꿈나무 댓츠미
이전 포스트

[UML][국비교육] Day 54

다음 포스트

[UML][국비교육] Day 56

0개의 댓글