소단자료

전공-소프트웨어공학

Oct 22, 2022

소단위 명세서
소단위명세서^MiniSpec (이후내용)
Mini Spec (이어서)

소단위 명세서

Mini-Spec

자료흐름도의 최하위 처리가 어떤 기능을 하는지에 대해 기술한 것

목적: 입력 자료흐름을 출력 자료흐름으로 변환하기 위해 어떤 일이 수행되는지를 정의하기 위해 각 처리기들이 수행하는 업무 절차를 상세히 작성하는 것

모듈 간의 계층 구조 (그리고 이에 대한 평가)

요구사항

소단위명세서는 사용자나 시스템 분석가가 검증할 수 있는 형태로 표현되어야 한다.

일상에서 사용하는 언어는 애매모호하기 때문
소단위명세서는 여러 계층의 사람들이 효과적으로 의사소통을 할 수 있는 형태로 표현되어야 한다.

소단위명세서를 작성하는 시스템분석가뿐 아니라, 사용자, 관리자, 감시자, 품질보증 담당자 등 다양한 사람들이 읽고 이해할 수 있어야 하기 때문
소단위명세서는 설계와 구현사항에 대해 임의로 결정하지 말아야 한다.

기술 방법

소단위명세서에 사용되는 도구는 다음과 같다.

구조적 언어_{Structured English}

절차적 표현에 유리하다.
의사결정 표^{Decision Table}

규칙에 따른 의사 결정 표현 시 유리하다.
의사결정 트리_{Decision Tree}

규칙에 따른 의사 결정 표현 시 유리하다.
선/후 조건문^{pre-post condition}

구조적 언어

자연어의 부분집합으로 기술. 최소한의 한정된 단어들과 문형만 사용.

평가 방법

응집력(응집도)
결합도

DT1을 DT2로 확장 (elementary rule)

<29 of 54>

condition 하나 당 2개의 elementary rule이 존재해야 한다(Y or N)
각 elementary rule은 서로 달라야 한다.
각 elementary rule은
k개의 조건에 대해 2^k rule
같은 elementary rule이 있으면 중복 명세 (DT2에서 C1:Y와 C2Y의 경우가 있겠네요)
동일한 룰에 대해서 취해지는 액션이 다른 경우를 모호한 명세라고 함.

예를 들어 R11과 R22가 있겠네요~
모호성 -> 눈에만 그렇게 보일수도 있고 실제로 애매할 수도 있다는거임~
모호성이 논리적으로 불가능하다면 눈에 보기에는 그렇다 라고 말할 수 있다.

예를 들어 x>60 그리고 x<40 이건 동시에 일어날 수 없는 일이죠? 그러므로!!!!! 보기에 애매모호한 규칙이다 라고 부르갰읍니다. 아직 발생한건 아니고 보기에만 논리적으로 안맞는다 이것을 “보기에는 모호한 규칙”
그렇기에 “보기에 애매한 규칙”은 에러가 아닙니다
만약 보기에 애매한 규칙이 real이면 이것을 모순^{contradiction}이라고 부르갯읍니다
Contradictory Specification. (모순된) 이라고 부름

<32 of 54>

그냥 PPT 보샘

논리적인 에러가 존재하다면 추정을 해야한다.

USE OF KARNAUGH MAPS (K - map)

카나프맵을 이용해서 steel의 grade를 측정하는 예시가 있어요 정말로 기분좋아지는거야

3개의 condition들은 독립적이고, decision table은 incomplete하다(빈구멍이 존재하는거에요~)

근데 K-map 사용 안했으면 이러한 사실을 알 수 없었을 것! 든든하다 K-map!

<36 of 54>

또 다른 예시가 있어요~정말로기분좋아지는거야

<37>

? 이건 incomplete 한 거고

A1A4 이렇게 2개잇는건 모호한 거에요~

REDUNDANCY ELIMINATION

중복 제거

이거 아시죠? xy + xy^ 를 x로 하는거 이런거 이산수학에서 배운거

그리고 카나프맵에서 어떻게 합치는지도 배웠으니까 아시리라고믿습니다~

<45>EXAMPLE-REDUCTION OF RULES IN WORD STATEMENT

에서 예시가있어요~

이걸 덱압축 하는 내용입니다~^^

<49 of 54> 이것도 예시임. 기차 예매 시스템이네요

Sometimes Decision trees are more appropriate to explain to a user how decisions are taken

교수?가?시험문제를 어떻게내느냐? 굉장히 어렵게 내자면은 <34 of 54>의 그 왼쪽 그림을 오른쪽 Decision Tree로 바꿔라. 같은 거죠. 하지만 그렇게 내고 싶지 않다네요. 구조적언어.Decision Tree.Decision Table 비교라고 강조함

Decision Tree를 제시해주고, Decision Table로 바꿔봐라 도 할 수 있갰죠~`??~???

SOME PEOPLE FIND DECISION TREE EASIER TO UNDERSTAND

Observe incompleteness evident in the equivalent Decision Table is not evident in the Decision tree

아주 답을 가르켜준다고 말함. 위에 내용 잘 분석하셈. 이건 Decision Table의 장점

If the testing sequence is specified and is to be strictly followed the Decision tree is simple to understand.

테스트할때 순서를 따라야한다면, Decision Tree가 더 이해하기 쉽다. 이건Decision Tree의 장점

<53>

아예 3개를 비교했네요 꼭 외우샘

가독성(Readable) 측면에서는 Structured English가 최고다

그렇다면 언제 Structured English, Decision Table, Decision Tree를 사용할 것인가?

Use Structured English if there are many loops and actions are complex

action(순차, 반복)에 초점이 맞춰져 있는 경우 Structured English는 좋다.

근데 action(조건)은 별!루
Use Decision tables when there are a large number of conditions to check and logic is complex

조건이 너무 많고 논리가 복잡할 때에는 Decision Table로 기분이 좋아지는거야~
Use Decision trees when sequencing of conditions is important and if there are not many conditions to be tested

얘는 조건이 많지 않아야된대

소단위명세서^MiniSpec (이후내용)

Mini-Specification for Process (+ Data)

데이터에 대한 명세는 자료사전(DD) 에서 했구요, 프로세스에 대한 명세는 소단위명세서(MiniSpec)에서 합니다.

즉, 소단위명세서는 프로세스가 하는 역할(기능)을 명세합니다.

구조적 언어^{Structured English}

절차에 초점을 맞추는 레후
의사결정표^{Decision Table}
의사결정트리^{Decision Tree}
선후조건^{Pre-Post Condition}

1번은 절차(어떻게?)에 초첨을 맞추는 레후

사과를 씻고 깎고 썰고 설탕을 넣고…

2~4번은 무엇 에 초점을 맞추는 레후

사과(선조건^{Pre Condition}) -> 사과잼(후조건^{Post Condition})의 중간과정(절차)은 관심없는레후

소단위명세서는 사용자나 시스템 분석가가 검증할 수 있는 형태로 표현되어야 한다.
일상에서 사용하는 언어(자연어)는 애매모호하다.

-> 반복이나 조건을 표현할 수 있는 단어를 추가한 구조적 언어를 사용한다.

구조적 언어의 예시는 PPT에 나와있는 거에요~
이것을 표로 나타낸 것이 바로 의사결정표. Condition과 Action을 나타냈네요 이것도 PPT에 나와있는 거에요~

씻었니? 깎았니? 썰었니? 설탕을 넣었니? 가 Condition 이겠죠~
의사결정트리는 의사결정표를 트리로 표현한 거에요~ 정말로 기분좋아지는거에요 ~

(PPT에 나와있는 거에요~)
소단위명세서의 요구사항
- 소단위명세서에는 여러 계층의 사람들이 효과적으로 의사소통을 할 수 있는 형태로 표현되어야 함
  
  여러 계층의 사람들
  
  소단위명세서를 작성하는 시스템 분석가 뿐 아니라, 사용자, 관리자, 감사자, 품질보증 담당자 등을 말한다.
- 소단위명세서에는 설계와 구현사항에 대해 임의로 결정하지 말아야 한다.
- 검증이 쉬어야 한다.
소단위명세서의 역할과 특성

구조적 언어를 선호하는 레후 Why? 어떤 것이든 표현할 수 있으므로
소단위명세서 기술 방법

오직 최하단위 단계의 처리만 기술한다. 몰라 PPT에 있는 레후~
구조적 언어의 개념

우리가 일상 사용하는 자연어의 부분집합으로 기술하는 언어.
- 자연 언어의 장점
  
  업무 중심언어, 신속한 작성, 사용자와 익숙함
- 구조적 프로그램의 장점
  
  간결성, 명확성, 제한된 단어, 제한된 문형, 제한된 구조
사용규칙같은건 PPT에 남아있는거에요~
구조적 언어의 작성 지침
1. …
2. …
3. 제어구조를 중첩해 사용할 때는 중첩에 따라 요철 모양(Indentation)을 사용해 혼돈을 피하는 것이 좋다
  
  ❗ ❗ ❗ 들 여 쓰 기 를 하 라 고 ❗ ❗ ❗
선후조건문을 작성하는이유
- 가정
  
  선조건: 임의의 정수 입력: N
  
  후조건: 1부터 N까지의 합
  
  프로세스는 뭐 s=n(n+1)/2갯죠?

Mini Spec (이어서)

Incompleteness
Ambihuity
Contradiction
Redundancy

을! Decision table에서 검출할 수 있다!

Decision table은 프로세스가 너무 복잡하거나 조건이 많을 때 대안으로 사용된다.

뭐 나머지 Structed English나 Decision Tree 같은 것도 영어 ppt에 있읍니다..

컨디션

Y은 yes, N은 no, -은 상관없음
액션

액션 X는 수행해야 하는 액션을 의미

액션 -은 수행 굳?이

컨디션 -와 액션 -는 다르다는 것을 주의

구조적 언어(=절차적 언어) Structed English(=procedural language)

Good Example: Give discount of 20%
Bad Example: Give substantial discount

그리고 연산자 사용할 수 있음

Structured English is procedural.
Most managers and users are not concerned how data is processed-

they want to know what rules are used to process data.
Specification of what a system does is non–procedural.
Decision Tables are non-procedural specification of rules used in processing data

(Decision Table은 비절차적인 방법으로 기술한 것이다.)

뭐…영문 PPT갖고 계속 설명하시는데..그거보세요..

테이블을 자동을로 번역해주는 알고리즘도 존재한다.
테스트는 오류를 발견해야합니당~

왠지모르겠는데 ppt 6.2.4 강조

그리고 condition 순서는 중요하지 않음, 근데 action 순서는 중요함!

Rule은 순서 상관없다.

오직! Order of Listing Actions만이 중요하다!

PPT에 많은 예시가 나와있으니 꼭 살펴봐서 정말로 기분좋아지는거에요~

condition은 3개니까 경우의수는 8갠데 R이 4개밖에 없다 => 전에 말했듯이 Decision Table은 Imcomplement한거에요~

그리고 ppt 내용중에 condition entries는 Y나 N일 필요는 없다고 하는데, 이건 사실 눈속임입니다… 아시갯죠?

조건이 굉장히 단순해지는거에요~ 이것을 EEDT(Extended Entry Decision Tables, 확장 의사 결정표 정도로 번역할 수 있갰내용)

MEDT라는것도있음..(Mixed) 근데 뭘 사용하든

어쨋든 구조적 언어로 설명한 내용은 다양한 계층의 사용자가 쉽게 이해할 수 있어야해!

(아무거나 막써도된다고는 하지만..)

복잡한 규칙이 존재할 땐 Decision Table을 쪼갤 수 있는레후

(오늘의 결론) 사용자가 쉽게 이해할 수 있어야 한다 ^-^