<6> SWModel_UML, Usecase diagram, Class diagram

이 글은 기말고사가 2일하고 16시간 남은 학부생이 기말고사 암기를 위해 작성한 내용입니다... 내용은 지현박교수님의 강의자료를 참고하였음을 밝힙니다...........🎀

 

 

 

🎀 소프트웨어 모델링

 - 모델: 대상을 특정 관점을 기준으로 표현하는 것 / 모델링: 모델을 만드는 것 - 소프트웨어 모델: 수행해야 하는 기능의 관점에서 소프트웨어를 표현

• 논리적 모델: 시스템은 무엇.이며 어떤 기능을 해야 하는가
• 물리적 모델: 시스템이 실제 어떻게 구현되어야 하는지 기술적인 면을 고려하여 표현

- 모델링 3요소

• 규약: 모델링에 사용되는 요소의 정의
• 표현: 규약을 이용하여 모델링한 결과
• 명세: 표현된 모델에 대한 상세 내용을 서술하는 것

 

 

🎀 The Unified Modeling Language (UML)

: OO(Object Oriented) 분석 및 설계 과정에서 생성될 수 있는 다양한 모델에 대한 참고 사항을 설명함

 

-Views of UML (5)

1. Use-case view: 외부 액터의 관점에서 시스템의 기능적 측면을 바라보는 뷰 -유스케이스 다이어그램
2. Logical View: 시스템의 기능들이 내부적으로 어떻게 설계될 수 있는지 보여주는 뷰 -패키지, 클래스, 시퀀스, 커뮤니케이션, 액티비티 다이어그램
3. Component View: 컴포넌트와 컴포넌트의 관계를 보여주는 뷰 -컴포넌트 다이어그램
4. Concurrency View: 시스템 요소들 간의 동기/비동기, 상호작용에 대한 사항 등 시스템 요소들에 대한 처리 방식을 보여주는 뷰 / 프로세스와 프로세서의 할당. .. 개발자와 시스템 통합자를 위한 것 -다이나믹, 임플리멘테이션 다이어그램
5. Deployment View: 컴퓨터와 주변 장치로 구성된 시스템의 실제 배치를 보여주는 뷰 -디플로이먼트 다이어그램

 

---

 

🎀 관계 (R)

 

1) Dependency: 한 변화가 다른 것에 영향을 주는 관계(역은 무관)

 

 

2) Association: 연관관계 - binary, n-ary도 가능 

 

3) Generalization : 부모자식 관계 / superclass와 subclass / is-a-kind-of R

*parent가 사용되는 곳이면 어디든 child도 사용 가능 (역은 아님!)

 

 

4) Aggregation (약한 집합)

5) Composition (강한 집합)

*뒤에서 자세히 설명함

---

 

 

🎀 Use Case Diagram 

: Actor(시스템에 대한 사용자)와 Use case(시스템이 제공하는 기능)의 관계를 도식화 

 

* Actor은 non-human도 가능

* Actor에 의해 바라보는 관점으로 표현됨

 

 

⚠️ Use case modeling

• 시스템과 사용자 간의 인터랙션 식별
  • 액터 정의 필수
  • 모든 유스케이스 취합 -> 시스템의 모습
    • Actor 추출에 필요한 질문
      1. 주요 기능을 누가 사용?
      2. 운영 관리 및 유지 담당은 누구?
      3. 결과물을 가용하는 사람은?
      4. 시스템과 연관되어 상호작용해야 하는 시스템은?
      5. 함께 동작해야 하는 HW 장치는?
• 고객이 이해하기 쉽다는 장점
• 요.사를 모델링
  • 고객의 요.사를 추출하는 초기단계에 수행 
• SW test 시나리오 작성의 기반

*Use case는 어떤 일이 처리되는 단계 X .  시스템의 도움을 받아 처리하고자 하는 Actor의 요구작업

 

 

⚠️ Scenarios

: 시스템이 어떻게 사용될 수 있는지를 보여주는 실제 사례

 

- Usecase Scenario

• 유스케이스 이름, 시작하는 행위자, 시작하는 데 필요한 선행조건
• 유스케이스 목표
• 정상 시나리오(normal flow of events), 예외 시나리오(what can go wrong)
• 동시 발생 가능한 내용, 유스케이스 종료 조건

---

⚠️Usecase Relationship

 

1) 유스케이스가 다른 유스케이스를 포함하는 관계 

**포함되어지는 유케쪽에 화살표 머리를!

 

ex) 여러 유.케에서 공통으로 중복되는 시나리오가 있다 -> 공통 부분을 따로 분리하여 새로운 유케를 만들고, 새로 만든 유케를 각 유케에 포함시킴.

 

 

 

2) 유스케이스와 그 유스케이스를 확장하는 관계

** 기본 유케 쪽에 화살표 머리를 둔다

 

*참조되는 유스케이스를 Extended Usecase, 참조하는 유스케이스를 Base Usecase

((기본 유케 실행 -> 확장 포인트 조건 만족 -> 확장 유케 실행))

 

어떤 경우에 확장이 되는지 명시함!

 

3) 유스케이스를 상속하는 것 (일반화)

- 자식 유케는 부모 유케의 모든 행동과 의미를 물려 받음 + 자신만의 행동을 추가 가능 

actor 사이에도 적용 가능

 

---

🎀Class Diagram 

: 클래스들과 그들의 관계를 표시

 

클래스: 임의의 유사한 객체들을 명세하기 위한 스펙 / 각 객체들을 생성해내기 위한 템플릿으로 사용

[ 속성(attribute) + 메소드 (method, operation) ]

속성, 오퍼레이션이 없는 ! 이름만 가진 class도 존재 가능

 

 

⚠️클래스 추출방법

• 하나의 주제를 가져야 함
• 클래스 이름은 추상화를 가장 특징화하는 하나의 '명사'여야 함
• 명사는 클래스 이름, 동사는 클래스의 operation이 될 확률이 높음
• 고객, 사용자와의 상담(시나리오) + 문제 도메인 지식 + 기술적 경험 + 일반 상식에서 추출
  1.  명사 추출 -> 클래스 후보
  2.  클래스와 관련된 명사/형용사 추출 -> 속성 후보
  3.  클래스와 관련된 동사 추출 -> 메소드(operation) 후보
  4.  클과 클 사이의 관계를 나타내는 동사 추출 -> 관계(relation) 후보

 

 

---

⚠️Class 사이의 Relationship

 

1) 클래스가 개념적으로 서로 연결됨(Association)

0..1은 0에서 1까지

*rolename: 각 클래스마다 역할을 표시할 수 있음.

*하나의 클래스가 여러 클래스와 연관을 맺을 수 있음. 

 

*은 정해지지 않은 수

EX)

 

*{연관에 제약} 을 둘 수 있음. - or 제약으로 선택지에 대한 모델링 가능

*연관 클래스를 가질 수 있음.

 

 

2) 식별정보(Qualifier)

언제? - 일대다의 다중성 연관관계에서

왜? - 한 객체가 특정한 객체를 가려내어야 하는 상황 발생

어떻게? - 식별정보 지정

*효과: 일대다의 다중성 연관관계를 일대일 다중성으로 줄이는 효과!

 

3) 상속(Inheritance)

앞에서 말한 것과 동일 / 빈 화살표

 

 

4) Aggregation(약한 집합)

: 하나의 클래스가 여러 개의 클래스로 구성되어 있는 경우

= 부분- 전체(part of) = has a "consist of" R

*속이 빈 마름모 - 반드시 필요하지 않음(약한 집합) , 마름모가 향하는 곳이 전체임.

 

5) Composition(강한 집합)

: 각 sub 클래스가 오직 하나의 super 클래스에 대하여만 의미를 가질 때

*속이 채워진 마름모

 

 

6) Dependency

: 한 클래스가 다른 클래스를 사용하는 경우 (특히 operation이 다른 클래스를 사용하는 경우)

 

 

7) Interface and Realization 

인터페이스 : 클래스의 일정한 행동을 나타내는 operation의 집합. 다른 클래스에서 사용 가능

인터페이스를 실체화하여 다른 클래스에서&nbsp; 사용 가능

 

8) Abstract class 

: 객체를 생성하지 않는 클래스

*이태릭체 클래스명