1. BuyCar 클래스   //Driver 클래스와 집합관계  // Benz의 합성관계

public class BuyCar{

   private Driver bestDriver;  //​bestDriver 변수가 없습니다.   Benz클래스를 선언해야합니다

   private Benz carType;  //그냥 Car가 맞았음...ㅠㅠ

public BuyCar(Driver d){

   this.bestDriver = d;

   this.carType = new Benz();

}

}

2. Driver 클래스

public class Driver{

   private String name; //- private였다.......젠장

   private int age;

}

3. Benz 클래스

public class Benz ​extends Car{ //​//Car클래스를 상속하면서 Status 의존관계

   private static int price;

   public Status autoDrive(Status status){  // ​Staus클래스를 매개변수로 받아야 합니다.  //이것도 그냥 맞다고 하심....

      Status  s = status;

      return s;

   }

   protected void specialFunction(){}

 }

4. Status 클래스

public class Status{

   private int speed;

   private String engineStatus;

   private String oilStatus;

}

5. Audi 클래스

public class Audi extends Car{ // Car를 상속받는 일반화 관계

   private int price;

   public void saveMode(){}

   protected void specialFunctino(){}

}

6. Car 클래스

public abstract class Car{ ​//추상화 처리하는 것.... 완전히 잊었음..ㅠㅠ

   public void defaultFunction();

   protected abstract void specialFunction();

}

일반화///상속관계 키워드 extends 클래스 옆에 꼭 넣어야함...

실체화///인터페이스 키워드 implements 클래스 옆에 꼭 넣어야함...

의존// 클래스를 매개변수로 메소드에 활용하는 등의 방식

연관의존//클래스를 그냥 변수선언만 한 상태를 말함...1:1 직접연관 (그냥 선에 -◇ 였음)이라고 하고 1:N은 그냥 연관이라고 한다.

-◆

이상해도 합성이다.///ㅠㅠ

클래스내에서 다른 클래스를 생성자로 선언하여 사용 하는것 강한결합을 의미함.

'요구사항' 카테고리의 다른 글

클래스다이어그램 시험 정리  (0) 2022.09.02
클래스 다이어그램 관계 : 예제들  (0) 2022.08.26
시퀀스다이어그램 예제  (0) 2022.08.26
클래스 다이어그램 예제  (0) 2022.08.26
클래스 다이어그램 설명  (0) 2022.08.26

UML표시....선과 기호의 색이 있고 없고 차이로 표시된다.......

1.Generalization(일반화) :일반적으로 알고 있는 상속을 의미/ 실선에 비어있는 세모

2.Realization(실체화) : interface를 오버라이딩하여 구현한것 / 점선에 비어있는 세모

3. Dependency(의존) : 클래스간의 참조/ 메서드내에서 대상클래스의 객체 생성하고나 사용, 리턴받아사용하는 것/ 호출이 끝나면 연관된 클래스와의 관계는 끝남/ 점선과 화살표

 

4.Association & Direct Association(연관) Association은 다른 객체의 참조를 가지는 필드를 의미함 둘의 연관관계가 어떻게 되는지 숫자로 표시할 수 있음

1- 1개 표현

*-0~ㅜ 개의 표현

n... m : n부터 m까지의 연관관계를 맺음

양방향 연관관계를 가지며 1(Board):n(Comment) 의 관계를 표시한 예제 

 

5.Aggregation(집합) & Composition(합성)

연관관계와 특수한 관계로 Association의 집합관계를 나타냄/ Collection이나 Array를 이용하는 관계 / 하지만 Association으로 충분이 나타낼수 있는 관계로 1:N 연관관계를 나타낸 것이다. Aggregation은 실선에 빈 다이아몬드

 

Composigition은 연관관계에서 강한 결합관계를 의미 / 참조하는 클래스의 라이프 사이클이 종속적/실선에 채워져 있는 다이아몬드

좀 억스스럽다.

'요구사항' 카테고리의 다른 글

클래스다이어그램 시험 정리  (0) 2022.09.02
클래스다이어그램 시험전 복습  (0) 2022.09.01
시퀀스다이어그램 예제  (0) 2022.08.26
클래스 다이어그램 예제  (0) 2022.08.26
클래스 다이어그램 설명  (0) 2022.08.26

가장 기본적인 다이어그램 모습이다.

해본것에 의미를 둔다.....

<<analysisModel>> Analysis Model 선택후 add diagram선택하여 sequenceDiagram을 선택하면 되고

object 눌러서 화면에 박스 만들고

시간 순서대로 1.2.3.----줄줄히 그리면 되고

리턴은 선을 선택하면 general에서 General-> ActionKind의 값을 RETURN으로 변경하면된다.

해본것에 의의를 둔다....

잘모겠다.

 

이렇게 한다는 것인데.........

샘이 주신예제.........

 

사실 더 잘 모르겠다....아이구 머리아프다.

'요구사항' 카테고리의 다른 글

클래스 다이어그램 관계 : 예제들  (0) 2022.08.26
시퀀스다이어그램 예제  (0) 2022.08.26
클래스 다이어그램 설명  (0) 2022.08.26
유스케이스 다이어그램 설명  (0) 2022.08.26
요구사항 개요 설명  (0) 2022.08.26

@클래스 다이어 그램
- UML의 한 종류
- 시스템을 구성하는 클래스들 간의 관계를 보여줌
- 시간에 따라 변하지 않는 시스템의 정적인 면을 보여줌

@접근제어자
1. public(+)      : 어떤 클래스의 객체에서도 접근 가능
2. default(~)      : 동일 패키지에 있는 클래스의 객체들만이 접근 가능
3. protected(#)  : 클래스와 동일 패키지 또는 상속관계 있는 하위 클래스의 객체들만 접근 가능
4. private(-)      : 글래스 내에서 생성된 객체들만 접근 가능

@ 클래스 다이어그램 관계
1. 일반화관계 Generalization--일반적인 상속관계 //extends
2. 실체화관계 Realization--인터페이스 관계//implements

 

3. 의존관계 Dependency-- 의존부터는 참조를 하기 때문에 혼돈스러움. class자체를참조하는 것은 비슷한데

      의존은 참조후 return 값이 있다. string이던 int이던 있는데 연관관계는 void형식으로 함수 이행은 있어도 따로 return값 있지 않는것이 가장 편한 예이나 모든것이 그런것은 아니다.

메소드에서 클래스를 매개변수로 사용하면 의존관계. 의존과 연관은 같이 나타 날수 있다.


4. 연관관계 Association-- 다른객체의 참조: 도메인등에서 보통 사용되며 게시판의 댓글등을 예상하면됨

양방향 관계를 가지며 리스트로 값을 받으면 그냥 연관관계이고 1:1이면 직접 연관이다.

포인토////클래스내에서 변수를 그냥 선언하고 사용하는 것이 연관관계
5. 집합... 합성(composition)관계-- 강한결합을 의미: 클래스명이 변경되면 참조되는 new 클래스명이 자동으로 변경되며 그동안 했던 controllerdhk serveic등의 관계를 생각하면됨. 합성중요

포인토//////클래스내에서 new생성자를 통해서 변수로 선언된다.

'요구사항' 카테고리의 다른 글

시퀀스다이어그램 예제  (0) 2022.08.26
클래스 다이어그램 예제  (0) 2022.08.26
유스케이스 다이어그램 설명  (0) 2022.08.26
요구사항 개요 설명  (0) 2022.08.26
유스케이스 : 관계 표시 간단하게....  (0) 2022.08.26

@유스케이스 다이어그램
- 시스템의 기능적인 요구사항을 설명하기 위한 도구
- Actor와 시스템이 수행하는 활동간의 관계를 표시하며, 시스템의 기능적인 요구사항을 설명하기 위한 도구

@시스템의 범위(scope)
- 우리가 개발하고자 하는 시스템을 사각형으로 표시

@유스케이스
- 시스템이 어떤 서비스 또는 기능을 제공하는지 명세해 주는 것으로 타원형으로 표시
- 유스케이스 이름은 단순명료하게 기술
ex) 예금조회, 사용자 인증, 리뷰작성 등

@액터..<--졸라맨--> 
- 액터는 시스템 외부에 존재하며 시스템과 상호작용하는 모든 것
- 이벤트를 완결하기 위해 시스템과 상호 작용하는 개체
- 액터가 사람일 경우, 시스템과 상호작용하는 사용자에 의해 수행되는 역할(Role)을 나타냄

@액터의 종류
1. 프라이머리 액터(Primary Actor) <--사람-->
- 시스템을 사용함으로써 이득을 얻는 액터
- 보통 사람을 지칭하고사람모양으로 표기
- 보통 시스템 왼쪽에 표기
2. 세컨더리 액터(Secondary Actor) <-- 시스템-->
- 프라이머리 액터가 이득을 얻기 위해 도움을 주는 액터
- 보통 외부 시스템을 의미, <<actor>>로 표기
- 보통 시스템 오른쪽에 표기 -> 액터이름을 특정인으로 지정불가

@액터를 정의해야하는 이유
- 액터가 수행하는 역할은 유스케이스가 필요한 이유와 결과에 대한 관점을 제공
- 액터에 초저을 맞춤으로써, 시스템이 어떻게 구현될지가 아닌 시스템이 어떻게 사용될지에 집중하기 위함

@관계(Relationship)
-액터와 유스케이스, 유스케이스와 유스케이스 사이의 관계를 나타내며, 서로 상호 작용한다는 의미로 해석

@관계의 종류 <--보통 1,2,번 한다-->
1. 연관관계
- 유스케이스와 액터간 상호작용을 의미하는 관계
- 실선 화살표
2. 포함관계
- 한 유스케이스가 다른 유스케이스의 기능을 포함하는 관계(반드시 해야만 하는 관계)
- 점선 화살표    왼쪽에서 오른쪽-->
3. 확장관계
- 기본 유스케이스에 특정 조건이나 액터의 선택에 따라 발생하는 유스케이스(선택적으로 할수 있는 관계)
- 방향이 다른 점섬 화살표   <--오른쪽에서 왼쪽
4. 일반화 관계
- 유사한 유스케이스들 또는 액터들을 추상화한 하나의 유스케이스로 그룹핑으로 이해도를 높인 관계

'요구사항' 카테고리의 다른 글

시퀀스다이어그램 예제  (0) 2022.08.26
클래스 다이어그램 예제  (0) 2022.08.26
클래스 다이어그램 설명  (0) 2022.08.26
요구사항 개요 설명  (0) 2022.08.26
유스케이스 : 관계 표시 간단하게....  (0) 2022.08.26

@UML
@웹 프로젝트 진행순서
1단계. 착수
-제안요청서(RFP)
2단계. 요구 사항 정의
3단계. 요구 사항 분석
4단계. 설계 - uml 이 필요함
5단계. 구현
6단계. 테스트
7단계. 이관
8단계. 운영지원

@제안요청서(RFP)
-Request For Proposal
- 발주가(갑)가 특정 과제의 수행에 필요한 요구사항을 체계적으로 정리하여 제시함으로써 
제안자(을)가 제안서를 작성하는데 도움을 주기 위한 문서

@요구사항
- 문제의 해결 또는 목적 달성을 위하여 고객에 의해 요구되거나, 
 표준이나 명세 등을 만족하기 위해서 시스템이 가져야할 서비스 또는 제약사항
- 고객이 요구한 사항과 요구하지 않았더라도 당연히 제공되어야 한다고 가정되는 사항들

@요구사항의 중요성
- 참여자들로 하여금 개발되는 소프트웨어 제품을 전체적으로 파악하도록 하여 
 의사소통 시간을 절약하게 해주는것
- 상세한 요구사항이 있어야만 산정이 가능하고, 이를 기반으로 계획을 세울 수 있기 때문이다.

@요구사항의 분류
1. 기능적 요구사항(Functional Requirements)
- 목표로 하는 어플리케이션의 구현을 위해 소프트웨어가 가져야 하는 기능적인 속성
- 목표로 하는 제품의 구현을 위해 소프트웨어가 가져야 하는 기능적 속성
ex) Word -> 작성한 글을 저장, 편집, 보기, 프린트......
2. 비기능적 요구사항
- 어플리 케이션의 품질 기준 등을 만족시키기 위해 소프트웨어가 가져야하는 성능, 사용의 용이성, 신뢰도,
 보안성, 운용상의 제약, 안정성, 유지보수성 등과 같은 행위적 특성으로 시스템의 기능에 관련되지 않은 요구사항
ex) 응답시간, 처리량, 보안 등

@요구사항 정의서
- 서비스를 구현하기 위해 거론되는 다양한 요구사항을 명확하게 정리하기 위하여 작성한 것
- 요구사항 명세서라고도 하며 요구사항을 분석하여 명확하고 완전하게 기록하는 것
- 소프트웨어 시스템이 수행해야 할 모든 기능과 구현상의 제약조건에 대해 개발자와 관련자가 합의한
 스펙에 대한 사항을 명세한 것

@요구사항 명세서 <-- 정의서와 명세서를 분류하는 곳도 있음.

-하나의 항목에 대해서 상세하게 설명하는 문서

@ 요구사항 정의서 작성이유
- 프로젝트 전체 규모를 파악
- 구현 가능 여부에 대한 논의
- 커뮤니케이션 비용 절약
- 프로젝트 일정 계획 수립

@UML(Unified Modeling Language)
- 통합 모델링 언어- 설계관련된 약속
- 소프트웨어 공학에서 사용되는 표준화된 범용 모델링 언어로 소프트웨어 개념을 다이어그램으로
 그리기 위해 사용하는 시각적인 표기법.
- 프로그램 설계를 표현하기 위해 사용하는 그림으로 된 표기법을 위미함.
- 소프트웨어 시스템, 업무 모델링, 시스템의 산출물을 규정하고 시작화하며 문서화하는 언어이다..
<-- 따로 텍스트 형식이 아니라서 한번보면 기억남는 언어-->

@UML 필요 이유
- 시스템의 복잡성을 표준적인 표기법으로 모델링하여 단순하게 표현가능
- 팀 간의 의사 소통에 필요
- 대규모 프로젝트 구조의 로드맵을 만들때 유용 <-- 설계도와 같은 의미 -->
- 개발할 시스템 구축에 대한 기초마련
- 백엔드 문서용으로 사용하기 좋음 

@UML 종류
1. 유스케이스 다이어그램
- 시스템의 제공하는 기능과 이용자와의 관계 표현<--졸라맨 : 사용자가 프로그램을 사용하는 스토리로 구성-->
2. 클래스 다이어그램 <-- JAVA, DB처럼 클래스명/ 변수명/ 메소드명/ 기재하고 그대로 소스코드로 변경하는 것-->
3. 스퀀스 다이어그램 <-- 글래스 다이어그램 통해서 소스코드 작성하면 진행의 순서를 시간순으로 스토리를 만드는 것-->
==========================위에 3가지정도 알면됨
4. 액티비티 다이어그램
5. 콜라보레이션 다이어그램
6. 상태 다이어그램
7. 컴포넌트 다이어그램
8. 배포 다이어그램

@ 아래 문장을 유스케이스 다이어그램으로 표현해보자
1. 게시판 시스템을 만드려고한다. 액터는 사용자가 있다.
2. 사용자는 글을 만들수도 수정할수도 있다.
3. 글을 쓰거나 수정하는 경우 로그인을 해야한다.
4. 글을 작성할 때 경우에 따라서 그림파일을 업로드 할 수 있어야 한다.

 

점선 표시는 약속되어 있음.....

왼쪽에서 오른쪽 ----> 해야만 한다.

오른쪽에서 왼쪽은---> 할수 있다.

//

@관계의 종류 <--보통 1,2,번 한다-->
1. 연관관계
- 유스케이스와 액터간 상호작용을 의미하는 관계
- 실선 화살표
2. 포함관계
- 한 유스케이스가 다른 유스케이스의 기능을 포함하는 관계(반드시 해야만 하는 관계)
- 점선 화살표    왼쪽에서 오른쪽-->
3. 확장관계
- 기본 유스케이스에 특정 조건이나 액터의 선택에 따라 발생하는 유스케이스(선택적으로 할수 있는 관계)
- 방향이 다른 점섬 화살표   <--오른쪽에서 왼쪽
4. 일반화 관계
- 유사한 유스케이스들 또는 액터들을 추상화한 하나의 유스케이스로 그룹핑으로 이해도를 높인 관계  //

'요구사항' 카테고리의 다른 글

시퀀스다이어그램 예제  (0) 2022.08.26
클래스 다이어그램 예제  (0) 2022.08.26
클래스 다이어그램 설명  (0) 2022.08.26
유스케이스 다이어그램 설명  (0) 2022.08.26
요구사항 개요 설명  (0) 2022.08.26

+ Recent posts