자료구조 기말 프로젝트 제안

지금 까지 배워온 자료구조, 알고리즘을 이용하여 실생활에서 이용가능한 도구를 만들어보자..

배운 것들 : 스택, 큐, 리스트, 그래프 등

<< 1 >>  현황 자료수집

1. 현 엘리베이터 문제점 분석

학생수가 500 명이 넘는 큰 건물에 탑승자 10 명 정도의  엘리베이터가 1대 있음.

사람과 화물의 구분이 없음.

대부분 3~5 층 탑승자가 대부분임.

2. 현 시스템  위험 분석

- 층별 기판은 위아래 호출용만 있고, 엘리 안의 층선택기판 사용

- 알림벨 기능이 없어 오작동시 안전사고 위험 높음.

- 사용인원에 비해 엘리베이터가 적지만 무게 안정감은 있음.

- 추가 설치시 건물개보수 필요

- 엘리베이터 이외에 건물 양쪽에 계단이 있음

- 층수가 짧아 대기시간이 적다.

<< 2 >>  요구사항

1. 업무상 요구사항

사용시 필요사항 또는 추가사항 알려줄 것. 건물개보수 가능함.

2. 시스템 요구사항

- 2 줄짜리 엘리베이터 설치

- 비상시에 관리자 호출기능

- 무선제어기능도 가능 (외부접속모드 후에 무선제어가능하나, 안전관리상 고정식은 힘듬)

<< 3 >>  유스케이스 다이어그리기

기본적인 용어설명 :

- 유스케이스(다이어그리기) : 간단한 시스템 외부의 사용(상세)설명

- 액티비티  (다이어그리기) : 순차로직, 업무절차, 워크플로우를 기술하는 명세방법

        *** 초기노드-포크-액션-결정-플로우-병합-조인-끝노드(다음 초기노드)

- 클래스    (다이어그리기) : 시스템의 객체의 타입과 그들간의 다양한 정적관계의 기술

        *** 구성: 클래스프로퍼티(이름,속성,연관)와 오퍼레이션, 연결시의 제약사항

        *** 연관(방향성), 다중성(0, 0..n,*),

        *** 속성은 접근가시성(+public-공용, -private-개인, ~package, #protected)과

                이름(둘째속성은 큰글자), 속성타입 등이 있다.

- 객체(object)는 인스턴스(instatnce)가 다른 클래스와 연관을 맺지 않은 것이다. 

1. 시스템 개요.

엘리베이터는 1, 2의 두개로 구성되어있습니다.

각층에는 엘리베이터 문이 각각 두개씩, 그 옆에는 층선택을 할 숫자판이 있습니다.

사용자가 층수를 선택하면, 안전하게 문이 열리고 사용자가 탄 후에 목적층에서 내립니다.

엘리베이터 안에는 또다른 층수선택판과 비상호출버튼이 있습니다.

층별 그리고 엘리베이터 안에 메시지방송과 화면 그리고 알림벨이 안전사고 예방을 위해 설치되어있습니다.

2. 작업흐름도 (간단한 액티비티 수준)// 삭제가능

-1 승객이 엘리를 버튼을 눌러 호출한다.

-2 엘리가 신호에 따라 누른 층으로 온다.

-3 알림벨과 도착신호를 주고(메세지와 화면)

-4 문이 열린다.

-5 일정시간 문이 감지센서로 열린다.

-6 승객이 내린다.

-7 오가는 사람이 없으면 문이 닫히고 1)그곳에 머물거나 2)다른 층으로 문다.

3. 유스케이스

3.1 시스템 구성요소

	시스템 구성요소	구분	설명	비고
1.	사용자	사용자 1	층수를 선택한다. 목적지층으로 써비스받음
		사용자 2	시스템의 운행에 다중성을 위해 설정
2.	층수판	문밖의 층수판	선택가능층들의 숫자판. 비상호출가능키 있음.
		엘리베이터안	문밖과 같다.
3.	메시지 방법	도착메세지	1. 알림벨 2. 메시지‘몇층 문이 열립니다.’
		출발메세지	1. 메시지‘출발합니다.’
		화면표시	1. 엘리베이터 안팎에 층수이동표시
4.	문.		1. 메시지와 함께 작동 2. 문에 감지센서로 여닫기 (일정시간 열리고, 센서에 감지되지 않으면 닫힘)

☞☏☳ 불충분시 172.16.22.17 로 또는 공유방이나 직접 말씀하십시오.

3.2 유스케이스 다이어그리기

그림은 끼워넣기 할 줄 몰라 하이퍼로 됨.

3.2.1 유스케이스 설명

구분	사용자	엘리베이터  시스템
기본 작동 흐름	1. 목적층을 누른다.        6. 확인하고 내린다.	2. 목적층을 저장하여 이동한다.  3. 도착시에 알림벨이 울리며, 화면에 층수가 표시된다. 4. 메시지‘몇층 문이 열립니다.’ 5. 문이 열리며 문의 센서작동   7. 문이 닫히고 딴대로 간다.               :               :
1 대안 작동 흐름	승객초과시 대기
2 예외 작동 흐름	오작동시 비상호출	오작동시 비상호출

3.3    유스케이스  명세서

*** 수화가 작성한 것 조금 수정후 사용해도 됨.

3.3.1 사용자 선택층 상황도 - 1. 층수판을 누른다.  2. 메시지와 함께 문이 열린다.

                             3. 사용자 타고(제한점 채크) 문이 닫힌다.

                             4. 엘리베이터가 움직인다.

3.3.2 사용자 층별이동상황도 - 1. 층간이동의 반복작업과 화면표시

3.3.3. 사용자 목적층 상황도 - 1. 메시지 출력“몇층의 문이 열립니다.” 와 함께 화면표시

                              2. 알림벨이 울린다. 3. 문이 열리고 센서가 작동한다. 

                              4. 승객이 내린다.

                              5. 문이 닫힌다.

                                (-1.그 층에 머문다. -2.다른 층으로 움직인다. )

3.3.4 사용자 없는 경우에 대기상황 - 1. 곧바로 목적층으로 간다.

                                    2. 도착시 그 층에 머문다.

4. 시퀀스 다이어그램

그린 것 넣기

5. 기술적인 명세서(액티비티 다이어그리기)

액티비티 다이어그리기 및 일반화 또는 상속으로 클래스 다이어그리기 넣기

6. 클래스 다이어그리기

그린 것 넣기

7. 시스템 개발

7.1  시스템 개발환경

엘리베이터 성능구현 및 개선을 위한 H/W, S/W, N/W

7.1.1 하드웨어

엘리베이터 모형 :

모터            :

컴퓨터          : CPU 90Mhz 이상 5대

모터제어용 타겟보드 :

7.1.2 소프트웨어

OS             : LINUX, MICROSOFT WINDOWS 2000

개발언어        : C, LINUX-SHELL-SCRIPT

7.1.3 네트웨크 프로토콜

TCP/IP

7.2  구성도

7.3 시스템 구성요소

7.3.1 메인콘트롤 박스

7.3.2 플로우 모듈

1번 플로우모듈

1-[1..5 층] --  a. 제어판(control)  모듈

                b. 화면 모듈

                c. 센서 모듈   

2번 플로우모듈

2-[1..5 층] -- a. 제어판(control)  모듈

                b. 화면 모듈

                c. 센서 모듈   

7.3.3. 엘리베이터 카 모듈

엘리베이터 카모듈 --   a. 제어판(control)  모듈

                        b. 화면 모듈

                        c. 센서 모듈   

7.4. 메인 모터 모듈

8. 프로토 모델 제안서

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

* 요구사항 분류(Requirement Classification)

 

- 기능적 요구사항과 비기능적 요구사항

- 하나 이상의 상위레벨 요구 사항에서 추론되어서 드러나기도 하고 새롭게 나타나는 속성 또는 이해관계자 또는 다른 소스들에 의해 소프트웨어에 직접적으로 강요될 수 있음

- 제품이나 프로세스에 관한 것: 프로세스에 관한 요구사항은 계약자의 선택, 적용될 소프트웨어 프로세스, 표준에 출실한 것 등에 대해 제약사항이 될 수 있음

- 우선순위도 포함: 일반적으로 요구사항의 우선순위를 3레벨 또는 5레벨로 나눈다고 할 때 우선순위에 대한 평가는 전체 개발 비용과 구현 비용 사이의 균형을 맞추어야만 함.

- 요구사항의 범위도 해당

   - 범위: 소프트웨어와 소프트웨어 컴포넌트에 영향을 미치는 범위

   - 어떤 비기능적 요구사항은 개별 소프트웨어 컴포넌트에 할당할 수 없을 만큼 광범위할 수도 있음.  즉, 범위가 협소한 경우 수많은 설계를 선택할 수 있고 다른 요구사항의 달성에 거의 영향을 주지 않지만, 광범위한 요구사항은 소프트웨어 구조와 많은 컴포넌트 설계 등에 강하게 영향을 미칠 수도 있음

- 변경성(Volatility)과 안정성(Stabiltity)

   - 어떤 요구사항은 소프트웨어 라이프사이클 동안 바뀔 것이며, 또한 심지어는 개발 프로세스 동안에도 바뀔 것

   - 요구사항 변경이 생길 것 같다고 추측할 수 있다면 큰 도움이 될 것

 

 

* 개념적 모델링(Conceptual Modeling)

 

* 모델 선택에 영향을 미치는 요소

  - 문제의 본질

  - 소프트웨어 엔지니어의 전문성

     - 소프트웨어 엔지니어의 경험이 뒷받침된 모델링 표기나 방법을 적용시키는 것이 더 생산적일 때도 있음

  - 고객의 프로세스 요구사항

     - 고객은 고객이 선호하는 기호나 방법을 지정 가능

     - 이는 소프트웨어 엔지니어의 전문성 요소와 충돌이 될 수도 있음

  - 방법이나 도구의 유용성

     - 훈련이나 도구가 충분하지 않은 표기나 방법은 특정 타입의 문제에 적당하다 할지라도 적용되기가 어려움

 

* 개념적 모델링

* 아키텍처 설계와 요구사항 할당 (Architectural Design and Requirement Allocation)

 

* 아키텍처 설계와 요구사항 할당 (Architectural Design and Requirement allocation)

 

* 아키텍처 설계와 요구사항 할당 (Architectural Design and Requirement Allocation)

 

  - 현실 세계 영역에서부터 소프트웨어 컴포넌트에 이르기까지 매핑하는 작업이 항상 명확한 것은 아니기 때문에, 아키텍처 설계는 별도의 주제로서 다루어 짐.

  - 표기와 방법에 대한 요구사항은 개념적 모델링과 아키텍처 설계가 대부분 비슷

     - IEEE Std 1471-2000: 시스템 아키텍처와 소프트웨어 구성요소들을 여러 관점으로 표현하는 방법에 대한 기준 제시

 

* 요구사항 협상(Requirement Negotiation)

 

  요구사항 협상 = 충돌 해결 (Conflict Resolution)

 

  - 서로 모순되는 기능을 요구하는 두 이해관계자 사이의 충돌 해결

  - 요구사항과 자원 사이의 충돌 해결

  - 기능적 요구사항과 비기능적 요구사항 사이의 충돌 해결

 

  ===> 이해관계자 모두가 합의할 수 있는 조정안

  ===> 의사결정이 어떤 고객에게서 유래되었는지 추적할 수 있는 것도 계약상 이유로 중요함.