Meng's Algorithm

[소프트웨어 공학] 3. UML Class Diagram

Object

• Class 는 붕어빵을 만드는 틀이고, Object는 실제 붕어빵들이다.
• maxMiller가 Person이란 Class Object의 이름이다. 
• :Person처럼 때론 익명의 Object를 바로 만들어 바로 사용할 수 있다.
• Objects are instances of classes

Class

• Arrtibutes : Java로 따지면 필드
• Operations : Java로 따지면 Method
• 같은 클래스 타입의 객체라면 Attributes는 다른 값을 가질 수 있지만 , 행위 (Operation)은 같다.

Class Variable and Class Operation

• Class variable (= class attribute, static attribute) : 클래스당 하나만 정의된다. 모든 클래스의 인스턴스로부터 공유된다.
• Class operation (= static operation) : static 형의 공유되는 메소드
•  # 는 Protected, +는 Public , -는 Private
• Class variable 또는 Class operation은 밑줄이 있다.

Abstract Operations and Classes

• body가 없는 operation이다.
• <-> Concrete Operations and Classes
• 추상 클래스는 인스텐스를 만들수 없다.
• Abstract operation이 하나라도 포함한다면 Abstract Class다. (역은 참이아님)
• Abstract operation이 없어도 Abstract Class일 수 있다. 

•  <<abstract>>으로 표기하거나 {abstract} property를 준다. 
• 이름이 기울어진 글씨체라면 abstract class이다. 

Interfaces

• UML interface는 abstract operation의 집합이다.
• Provided interfaces : 클래스 또는 컴포넌트로부터 실현된, 구현된 인터페이스를 말한다. (일반적 생각하는 인터페이스)
• Required interfaces : 클래스 또는 컴포넌트로부터 공급을 받아야 하는 인터페이스 이다. ( 클래스안에 인터페이스 에 관한게 쓰인 경우)
• 노란색이 Provided , 파란색이 Required 인터페이스 임.

Types of class relationship

Dependency

Association

[소프트웨어 공학] 2. UML Overview

Software Modeling

• Model = Abstraction of the system 
  핵심적인 것만 담은 시스템의 추상화라 할 수 있다. 
  복잡도를 낮추기 위해 모델링을 사용한다.
• 고객, 개발자, 분석가 등등의 시스템 디자인, 분석등의 매개체 역할을 한다.
• Unified Modeling Language ( UML ) : 모델링의 표준

Categories of UML diagrams

• Structure Diagrams (구조적 다이어그램) : what things must be in the system
  • Class diagram
  • Component diagram
  • Deployment diagram
  • Composite diagram
  • Object diagram
  • Package diagram
• Behavior Diagrams (행위적 다이어그램) : what must happen in the system
  • Activity diagram
  • State diagram
  • Use case diagram
• Interaction Diagram (상호작용 다이어그램) : the flow of control and data among the things
      사실은 행위적 다이어그램에 포함된다.
  
  • Communication diagram
  • Interaction overview diagram
  • Seqeunce diagram
  • Timing diagram

Use-Case Diagram

행위자들과  Use case들 간의 독립성을 나타내는 함수를 보여준다.

Activity Diagram

한 스탭 스탭 마다의 workflows 제어 전부를 보여주는 flow chart이다. 

State Diagram

Activity 다이어그램과 비슷해보이지만 목적이 다르다. 우선 State Diagram은 대상을 1명으로 한다.

그리고 어떠한 State로 변하는지 다이나믹한 행동을 묘사한다. 

Sequence Diagram

액터들과 시스템 시스템의 객체들간의 다이나믹한 행동을 묘사한다. 

UML and Development Process

소프트웨어 개발 프로세스에서의 UML을 각각 단계마다 연결 시켜보았다.

[소프트웨어 공학] 1. 소프트웨어 개발 프로세스

그림 용어 설명

• 하나의 개발 프로젝트는 많은 액티비티로 구성되어 있다.
• 하나의 액티비티는 많은 tasks로 구성되어 있다. 
• 하나의 Task는 많은 WorkProduct를 생산하고 리소스들을 사용한다.
• Work Product : System, Model, Document
• Resource : Participant, Time, Equiment

소프트웨어 개발 프로세스

• SDLC 소프트웨어 개발 생명주기라고도 부른다. 
• 여러 액티비티와 그것의 관계를 나타낸 것
• 소프트웨어 개발에 질서를 부여한다.

Fundamental Activities in 소프트웨어 개발 프로세스

요구사항 추출 -> 분석 -> 시스템 설계 -> 디테일 디자인 -> 구현 -> 테스트

소프트웨어 개발 프로세스 모델

• SDLC model 이라고도 부른다.
• 소프트웨어 개발 프로세스의 추상적 표현이다
• 대표적 소프트웨어 개발 프로세스 모델
  
  • 순차적 모델
    • Waterfall model
    • V-model
  • 반복적 모델
    • 나선형 모델
    • Unified Process (RUP)

• Plan - driven Process : 미리 계획하고 잘되는지 관찰한다. 
• Agile Process 애자일 프로세스 : 일부 계획하고 또 일부 계획 하는 점증적 계획을 한다. 고객 요구사항 변화에 적응이 쉽다.
• 현실에선 둘 다의 특성을 가지고 있는 경우가 많다.

소프트웨어 프로세스 모델에서 어떤 건 옳고, 어떤 건 나쁜건 없다.

Sequential Development

Waterfall Model

전 단계가 검증되고 리뷰되어야만 다음단계가 시작된다. 

전단계로 되돌아 갈 수 없다. ( 있어도 타격이 크다)

Plan - driven 적 접근

• Advantages :

  심플하고 단계 구분이 잘 나뉘어있다. 

  요구사항이 쉬운 경우, 대규모 시스템인 경우 적합하다. ex) 비행기 

  관리자 측면에서 유용하다.

• Disadvantages :

  요구사항이 일찍 명세화되고 고정되어 있음을 가정한다. 

  하드웨어의 변화가 필요하거나 급진적 기술 변화가 있다면 좋지 않다.

  big bang의 방식 즉, 모든 것을 한번에 만들어내므로 위험에 취약하다.

  요구사항이 변경 불가능하므로 애초에 필요 이상으로 많아진다.

  상당한 량의 문서가 만들어 진다.

V - Model

Waterfall의 변형. Test단계를 좀 더 세분화 한 모델.

자동차 시스템과 같이 하드웨어와 소프트웨어가 합쳐진 경우

기능이 엄밀하게 사용되어야 되는 경우 쓰인다.

• Advantages :

  높은 품질과 테스트 효능이 강하다.

• Disadvantages :

  Waterfall과 같은 단점을 갖는다.

위 두 모델 모두 요구 사항을 변경하는데 취약하다

Development of prototype

프로토타입에 잘 이해하지 못하는 부분, 위험한 부분을 먼저 간추려 넣는다. 이것으로 더 구체적인 피드백을 앞서 받을 수 있다. 

• Advantages :

  요구사항이 쉽게 견고해진다.
  요구사항이 나중에 고정되도 된다.
  프로토타입을 만든 경험이 실제 개발에서 도움이 된다. 
  
  

• Disadvantages :

  예상보다 비용과 일정이 더 들어갈 수 있다.

Iterative and Incremental Development

   한번이 아닌 여러번에 거쳐 만든다.

   ex) UP, Agile....

• Benefits :

  위험을 줄임
  수정에 유연
  피드백에 유용
  여러번 테스트를 거치기 때문에 높은 품질

• Drawbacks :

  구조와 디자인이 최적이 아닐 수 있음
  다시 일하는 경우가 증가하고, 총 비용이 증가할 수 있다.

• 적합성 :

  장기적인 프로젝트의 위험을 줄여야 할 때 

  모든 요구사항을 확정 할 수 없을 때 

  응답시간이 중요할 때

Spiral Model : 나선형 모델

단계가 딱 정해져 있지 않다.

반복적 해결로 위험 요소를 해소한다

1. 개체 생성 ( Objective setting)
   단계를 위한 특정한 객체를 식별한다
2. 위험 해소 (Risk reduction)
3. 개발 및 검증 
4. 계획 
   다음 사이클에 대한 계획을 말함

Rational Unified Process (RUP) & Unified Process (UP)

반복적이며 아키텍처 중심적이고 유스케이스 중심이다. 

1. Inception Phase (도입 단계)

   사업에 타당성, 실현가능성 확인 
   비용 기간 범위 산정

2. Elaboration Phase (구체화 단계)

   리스크를 줄이고 견고한 아키텍쳐를 만든다

3. Construction Phase (구축 단계)

   프로토 타입을 기반으로 인도 가능한 최초 실행 버전의 소프트웨어 개발

4. Transition Phase (전이 단계)

   사용자가 테스트 해본다

📌 Tip : 각각의 단계가 소프트웨어 개발 프로세스 단계로 착각하는데, SDLC는 계속 이루어 지고 있다 ! 다음 사진을 보면 이해가 간다.

Waterfall이 리스크가 높음을 볼 수 있으며, 폭포수 단계는 중간 까지 눈에 보이는 성과가 없다.