'사는 이야기 > 5dols story' 카테고리의 다른 글
| 메신저와 외로움과의 관계 (0) | 2008.10.26 |
|---|---|
| 여드름 (0) | 2008.10.26 |
| 과제 (0) | 2008.10.26 |
| 버섯 이야기 (0) | 2008.10.26 |
| 수능 (0) | 2008.10.26 |
'분류 전체보기'에 해당되는 글 239건
- 2008.10.26 아침에 일어나기
- 2008.10.26 과제
- 2008.10.26 버섯 이야기
- 2008.10.26 수능
- 2008.10.26 공대생 이야기3
- 2008.10.26 공대생 이야기2
- 2008.10.26 공대생 이야기
- 2008.10.26 Food website Project SRS (Software Requirements Specification) - IEEE standard 1
- 2008.10.26 Food website Project (Proposal)
- 2008.10.26 Library Project SPDD (Software Project Database Design)
- 2008.10.26 공부를 시작한다는 것은.
- 2008.10.26 4. Class Diagram
- 2008.10.26 어디선가 무슨일이 생기면
- 2008.10.25 사람을 죽이는 법
- 2008.10.25 잠 2번째 이야기
- 2008.10.25 잠
- 2008.10.25 여자의 영향력
- 2008.10.25 생일
- 2008.10.25 이모티콘
- 2008.10.25 호환마마보다 더 무서운 것
- 2008.10.25 삽질
- 2008.10.20 XST 취약성 관련 GET, POST 외에 죄다 막아버리기
- 2008.10.20 Liberary Project SRS ( Software Requirements Specification )
- 2008.10.06 아파치 웹서버 모니터링하기
- 2008.09.30 인터넷 페이지 오류들
'사는 이야기 > 5dols story' 카테고리의 다른 글
| 버섯 이야기 (0) | 2008.10.26 |
|---|---|
| 수능 (0) | 2008.10.26 |
| 공대생 이야기2 (0) | 2008.10.26 |
| 공대생 이야기 (0) | 2008.10.26 |
| 공부를 시작한다는 것은. (0) | 2008.10.26 |
'사는 이야기 > 5dols story' 카테고리의 다른 글
| 수능 (0) | 2008.10.26 |
|---|---|
| 공대생 이야기3 (0) | 2008.10.26 |
| 공대생 이야기 (0) | 2008.10.26 |
| 공부를 시작한다는 것은. (0) | 2008.10.26 |
| 어디선가 무슨일이 생기면 (0) | 2008.10.26 |
'사는 이야기 > 5dols story' 카테고리의 다른 글
| 공대생 이야기3 (0) | 2008.10.26 |
|---|---|
| 공대생 이야기2 (0) | 2008.10.26 |
| 공부를 시작한다는 것은. (0) | 2008.10.26 |
| 어디선가 무슨일이 생기면 (0) | 2008.10.26 |
| 사람을 죽이는 법 (0) | 2008.10.25 |
Food website Project SRS (Software Requirements Specification) - IEEE standard
소프트웨어공학/산출물 정리 2008. 10. 26. 02:37이건 Food website의 요구사항 정의서이다. 목차는 IEEE stardand를 거의 따랐다. 번역은 우리 플젝할 때 의석이형이 해주었다..ㅎ (유일한 유학파..-0-;;) 어쨋든 뭐 보면 다들 이해하리라 믿는다..ㅋ
Software_Requirements_Specification_ver1.1_.zipTable of Contents 3
1.0 Purpose 5
1.1 Introduction 5
1.2 Scope 5
1.3 Glossary 5
1.4 References 5
1.5 Document overview 5
2.0. General Description 6
2.1. Product Functions 6
2.2. User Characteristics 6
2.3. Constraints 6
2.4. Assumptions and Dependencies 6
3.0 Specfic requirements 7
3.1 Explanation of category ID and Inscription rule 7
3.2 Functional requirements 7
3.2.1 Functional requirements definitions 7
3.2.2 The core functional requirements deduce 7
3.2.3 Functional requirements table 8
3.2.3.1 System requirements 8
3.2.3.2 User requirements 9
3.2.3.3 Information requirements 10
3.3 Non-functional requirements table 10
3.3.1 Non-functional requirements definitions 10
3.3.2 Non-functional requirements 10
3.4 Use cases modeling 13
3.4.1 System use cases 13
3.4.2 Use cases summary 13
3.4.3 Detail Use cases scenario 14
3.4.3.1 UC_Sign_up 14
3.4.3.2 UC_Login/logout 14
3.4.3.3 UC_Total_member_management 15
3.4.3.4 UC_Information 17
3.4.3.5 UC_Board_management 18
3.5 Sequence Diagram 19
3.5.1 UC_Sign_up 19
3.5.2 UC_Login/logout 20
3.5.3 UC_Total_member_management 21
3.5.4 UC_Information 23
3.5.5 UC_Board_management 23
3.6 Function description 24
3.7 ERD 25
3.7.1 E-R Diagram 25
3.7.2 Table list 26
3.7.3 Table description 26
3.7.3.1 UC_Login/logout 26
3.7.3.2 UC_Information 27
3.7.3.3 UC_Board_management 27
4.0 External interface requirements 29
4.1 User Interfaces 29
4.1.1 Link 29
4.1.2 Main page 29
4.2 Hardware Interfaces 30
4.3 Software Interfaces 30
4.4 Communication Interfaces 30
'소프트웨어공학 > 산출물 정리' 카테고리의 다른 글
| File Management Program Project (0) | 2009.02.01 |
|---|---|
| Food website Project SPMP (Software Project Management Plan) (0) | 2008.10.26 |
| Food website Project (Proposal) (0) | 2008.10.26 |
| Library Project SPDD (Software Project Database Design) (0) | 2008.10.26 |
| Liberary Project SRS ( Software Requirements Specification ) (0) | 2008.10.20 |
Myfood2007(ver1.1).pptx
CBD20070313.pdf이 프로젝트는 학교 주변 먹거리 관련 홈페이지를 만드는게 목적이었다. 정확히 내가 소프트웨어 공학을 처음 입문할 때 한 프로젝트라고 해야하나..? 음.. 각 문서가 연결이 되지 않는 치명적인 단점이 있지만..-0-;; 목차나 제안서와 견적서등은 결코 회사에서 사용하는 것보다 뒤지지 않는다고 말하고 싶다. ㅋ
Myfood2007.pptx는 제안서이다. RFP가 어따 놨는지 없어서 그냥 제안서만 올린다..--;;
그리고 CBD20070313.xls는 프로젝트 견적서이다.
'소프트웨어공학 > 산출물 정리' 카테고리의 다른 글
| Food website Project SPMP (Software Project Management Plan) (0) | 2008.10.26 |
|---|---|
| Food website Project SRS (Software Requirements Specification) - IEEE standard (1) | 2008.10.26 |
| Library Project SPDD (Software Project Database Design) (0) | 2008.10.26 |
| Liberary Project SRS ( Software Requirements Specification ) (0) | 2008.10.20 |
| IEEE Standard for Software Unit Testing (0) | 2008.06.12 |
LibraryProjectERD.er1이 문서는 프로젝트의 ERD와 각 Table 명세가 되어 있는 DB 명세서라고 생각하면 된다.
뭐 이대로 만들어도 별로 무리가 없을 것이긴 한데 시나리오를 기반으로 구축하였기 때문에 일반적인 도서관과 구조 자체가 다를 수 있다.
목차이다.
1.0 ER Diagram 5
Logical Review 5
Physical Review 5
2.0 Table Detail Design 6
3.0 DDL CREATE SQL 10
3.1 저자 10
3.2 도서 위치 정보 10
3.3 출판사 정보 10
3.4 도서 정보 11
3.5 저자 서적 분류 11
3.6 회원 직급 11
3.7 대출 권한 12
3.8 회원 12
3.9 대출 정보 12
3.10 블랙리스트 13
4.0 Data loading 13
4.1 저자 13
4.2 도서 위치 정보 14
4.3 출판사 정보 14
4.4 도서 정보 16
4.5 저자 서적 분류 18
4.6 회원 직급 21
4.7 대출 권한 21
4.8 회원 21
4.9 대출 정보 22
4.10 블랙리스트 23
5.0 Grant SQL 23
'소프트웨어공학 > 산출물 정리' 카테고리의 다른 글
| Food website Project SPMP (Software Project Management Plan) (0) | 2008.10.26 |
|---|---|
| Food website Project SRS (Software Requirements Specification) - IEEE standard (1) | 2008.10.26 |
| Food website Project (Proposal) (0) | 2008.10.26 |
| Liberary Project SRS ( Software Requirements Specification ) (0) | 2008.10.20 |
| IEEE Standard for Software Unit Testing (0) | 2008.06.12 |
'사는 이야기 > 5dols story' 카테고리의 다른 글
| 공대생 이야기2 (0) | 2008.10.26 |
|---|---|
| 공대생 이야기 (0) | 2008.10.26 |
| 어디선가 무슨일이 생기면 (0) | 2008.10.26 |
| 사람을 죽이는 법 (0) | 2008.10.25 |
| 잠 2번째 이야기 (0) | 2008.10.25 |
UML의 다이어그램 중 어느 한 다이어그램이 중요하지 않다 말할 수는 없지만 클래스 다이어그램은 그 중 중요하다 할 수 있는 다이어그램이다. 필자가 시스템을 구축하면서 느낀 점을 보태어서 말한다면 만들어진 시스템의 정적구조가 엉망이라면 시스템의 구축이나 기능확장의 어려움이 막대하다 할 수 있다. 반면에 잘 만들어진 구조를 가졌다면 시스템 구축자체에서나 기능의 확장에 있어서 무리 없이 가능해진다. 물론 이렇게 잘 된 정적 구조의 중요성을 실감하기 위해서는 실제 시스템의 만들어보고 잘못된 구조로 인한 피해를 느껴봐야만 할 것이다.
만약 이 글을 읽는 독자 중에 시스템의 정적인 구조를 처음 설계하려는 사람이 있다면 되도록이면 빠른 싸이클로 반복을 하기 바란다. 왜냐하면 설계에 대한 충분한 경험을 가지고 있지 않고는 처음 설계한 구조가 시스템을 구축하기에 완벽하게 만족시키지 못하기 때문이다. 빠른 싸이클의 반복은 잘못된 구조의 수정 기회를 늘인다.
이제 클래스 다이어그램에 관한 내용을 알아보도록 하자. 실제 클래스 다이어그램의 내용은 한 회에 다 실을 수 없을 만큼 양이 많다. 글의 제목에서도 느낄 수 있는 것과 같이 클래스 다이어그램을 2내지3회의 분량으로 할 계획이다. 클래스 다이어그램이 이렇게 분량이 많은 이유는 클래스 다이어그램이 프로그래밍 언어들과 가장 직접적으로 연관을 맺고 있고 또한 아주 많은 부분에서 객체지향의 이론이 녹아들어가 있기 때문이다. 이번 호에서는 클래스 다이어그램의 가장 기본이 되는 요소들과 그 의미를 알아보도록 할 것이다.
1.클래스
그림 1 - 클래스의 표기
클래스의 표기는 그림1에서의 표기와 같이한다. 그림1의 좌측에 있는 것은 Attribute와 Operation이 축약되지 않은 표기이고 나머지는 축약된 표기이다.
클래스의 의미는 일반적으로 객체지향 언어에서 사용하는 클래스의 의미와 유사하다. 클래스라는 것은 시스템에서 동작하게 되는 하나의 개념의 추상화 도구로써 사용되며 추상화의 단계에 따라 클래스의 의미가 약간씩 차이가 생긴다. 만약 설계 당시에 추상화가 아주 높은 단계에서 이러한 클래스는 시스템에서 사용되는 하나의 역할로서의 의미를 가진다. 하지만 구현단계와 같은 추상화 단계가 아주 낮은 상태에서는 실제 객체를 생성하기 위한 클래스의의미를 가지게 된다. 이러한 단계의 구별은 사용자의 의도에 따라 적당히 사용하면 될 것이다.
클래스의 의미는 일반적으로 객체지향 언어에서 사용하는 클래스의 의미와 유사하다. 클래스라는 것은 시스템에서 동작하게 되는 하나의 개념의 추상화 도구로써 사용되며 추상화의 단계에 따라 클래스의 의미가 약간씩 차이가 생긴다. 만약 설계 당시에 추상화가 아주 높은 단계에서 이러한 클래스는 시스템에서 사용되는 하나의 역할로서의 의미를 가진다. 하지만 구현단계와 같은 추상화 단계가 아주 낮은 상태에서는 실제 객체를 생성하기 위한 클래스의의미를 가지게 된다. 이러한 단계의 구별은 사용자의 의도에 따라 적당히 사용하면 될 것이다.
2.Attribute와 Operation
Attribute와 Operation 의 표기 또한 추상화 단계에 따라 표기의 방법이 달라 질 수 있다. 예를 들어 구현단계에 근접하여 클래스 다이어그램을 도시하려 한다면 구현하기위한 언어에 밀접한 형태의 Attribute와 Operation 으로 나타내어야 하지만 추상화 단계가 높을 경우는 대략적인 의미 전달을 할 수 있을 정도로 표기하여도 된다. Attribute의 UML1.1 표준형식은 다음과 같다.
visibility name : type-expression! = initial-value { property-string }.
구조에 대한 설명은 프로그래밍 언어를 사용하여 본 사람이라면 쉽게 이해할 수 있을 것이다. Operation의 UML1.1표준형식은 다음과 같다.
visibility name ( parameter-list ) : return-type-expression! { property-string }
Attribute와 마찬가지고 구조는 쉽게 이해될 것이다. 여기서 한가지 짚고 넘어가야 할 부분이 Visibility부분이다. 언어에서 Visibility를 private와 protect, public으로 구분하듯이 여기서도 이러한 구분을 표시할 수 있다. 즉 private는 '-'로 protected 는 '#'로 public은 '+'로 표기함을 알아두어야 할 것이다.
3.클래스와 클래스의 상속관계(Generalization Relationship).
그림 2 - 상속관계
상속관계의 표기는 그림 2와 같이 닫혀져 있는 머리를 가진 화살표로 나타낸다.
상속의 의미는 일반 언어에서의 상속의 의미와 유사하게 상위클래스의 모든 특징과 행위를 하위의 클래스가 모두 이어받게 된다. 즉 다양한 클래스들의 나열에서 동일한 행위나 특징을 가진 여러 클래스들이 존재할 때 공통되는 부분을 상위 클래스로 만들 수 있다.
상속의 의미는 일반 언어에서의 상속의 의미와 유사하게 상위클래스의 모든 특징과 행위를 하위의 클래스가 모두 이어받게 된다. 즉 다양한 클래스들의 나열에서 동일한 행위나 특징을 가진 여러 클래스들이 존재할 때 공통되는 부분을 상위 클래스로 만들 수 있다.
4.클래스와 클래스의 연관관계(Association Relationship)
그림 3 - 연관관계
연관관계의 표기는 그림 3과 같이 실선으로 표기하게 된다. 연관관계의 의미는 두 클래스가 서로 어떠한 연관을 가지고 있다는 의미이다. 예를 들어 회사와 사원은 어떤 식으로든지 연관을 가지고 있다. 이것을 표현하기 위해서 연관의 관계를 사용한다. 물론 이러한 연관을 사용하기 위해서 UML에서는 표기의 확장으로 여러가지 장식(Adornments)들을 사용한다 여기서 사용되는 장식들로는 연관의 이름, 다중성(Multiplicity), 역할이름(RoleName) 등이 있다. 각 장식에 대하여 알아보면 먼저 연관의 이름은 어떠한 연관인지를 명시적으로 나타내게 된다. 다중성의 의미는 연관된 상대의 수를 표시하게 된다. 마지막으로 역할이름은 연관을 맺은 상태에서 상대 클래스에서 사용되어지게 되는 역할의 이름을 나타낸다.
5.클래스와 클래스의 집합연관관계(Aggregation Relationship)
그림 4 - 집합연관관계
집합연관관계의 표기는 그림 4와 같이 속이 빈 마름모 머리를 가진 실선으로 표기하게 된다. 집합연관관계는 연관관계의 일종으로 연관관계에서 쓰이는 모든 장식들이 다 쓰일 수 있다.집합연관관계를 쓰는 경우는 클래스와 클래스의 관계가 부분과 전체의 관계를 가질 때 표시할 수 있다. 예를 들면 자동차와 바퀴는 전체와 부분의 관계가 될 수 있다.
6.클래스와 클래스의 복합연관관계(Composition Relationship)
그림 5 -복합 연관관계
복합연관의 표기는 그림 5에서와 같이 속이 찬 마름모머리를 가진 실선으로 표기하게 된다. 복합 연관관계는 집합연관관계와 유사하게 전체와 부분의 관계를 나타내게 된다. 하지만 엄연한 차이점이 존재한다. 집합연관관계에서는 부분 클래스가 전체 클래스와 같은 생명시간을 가진다는 것이다. 즉 전체의 클래스의 객체가 소멸될 때 부분 클래스의 객체 또한 소멸되는 것이다. 예를 들어 우리가 흔히 말하는 윈도우를 전체로 보고 그 안에 들어가는 버튼을 부분으로 보면 이해가 쉬울 것이다.
7.클래스와 클래스의 의존관계(Dependency Relationship)
그림 6 - 의존 관계
의존관계은 그림 6에서와 같인 열려진 머리의 화살표를 가진 점선으로 표기한다.
의존관계의 의미는 한 클래스의 변화가 다른 클래스에 영향을 미칠 때 사용한다. 이러한 의존의 관계는 여러가지 관계에서 나타날 수 있다.
8. 클래스에서 사용자 정의 구역(User-defined compartment)
10. Interface
11. Parameterized Class (Template Class)
12. Utility
13. MetaClass
14. Enumeration
15. Stereotype
의존관계의 의미는 한 클래스의 변화가 다른 클래스에 영향을 미칠 때 사용한다. 이러한 의존의 관계는 여러가지 관계에서 나타날 수 있다.
8. 클래스에서 사용자 정의 구역(User-defined compartment)
그림 7 - 사용정의 구역 (user-defined compartment)
클래스를 구성하는 부분으로 이름구역, Attribute구역, Operation구역이 있음을 우리는 알고 있다. 이러한 클래스를 구성하는 세가지 부분은 UML에서 미리 정의하는 부분이고 이외에 사용자가 정의하여 작성할 수 있는 새로운 구역을 첨가할 수 있다. 이러한 사용자 정의 구역은 툴이 제공하는 환경에 따라 다양하게 제공된다. 만약 독자 여러분이 UML Modeling툴을 만든다면 사용자 정의 역역을 이용하여 순공학이나 문서화 등의 툴의 부가적인 기능을 돋보이게 할 수 있을 것이다.
9. Type and Implementation Class
9. Type and Implementation Class
그림8 - type and implementation class
지금부터 언급하는 내용은 클래스 다이어그램에 적용함에 있어서 스테레오타입(Stereotype)이나 컨스트레인트(Constraint)를 이용하여 기존 클래스의 의미를 확대하는 부분이다. 이러한 의미의 확대는 실제 업무에서 사용되는 개념과 좀 더 근접시키기위해 UML에서 표준으로 지정하고 있다.
먼저 Type의 경우 스테레오타입으로 'type'을 가진다. 이것은 객체가 가지는 Specification만을 표시한다. 그러한 이유로 실제로 언어에 바인딩되는 attribute나 method를 적는 것이 아니라 specification상에 나타나는 attribute나 operation이 반영된다. 반면에 Implementation class의 경우 실제 물리적인 언어에 바인딩되게 표현을 한다. Implementation class의 경우 스테레오 타입을 'implementationClass'를 기입하게 된다. Type과 iplementation class의 차이는 type을 실체화(Realization) 시킨 것이 Implementation class가 된다.
10. Interface
그림 9 - Interface
인터페이스 클래스의 경우 스테레오타입을 'interface'로 가지며 객체지향 언어인 java에서 사용되는 인터페이스의 의미와 동일하게 클래스의 행위만을 확정하고 있다. 이러한 인터페이스는 구현을 가지지 않으므로 abstract operation을 가지게 된다.
11. Parameterized Class (Template Class)
그림 10 - Parameterized Class
Parameterrized Class의 표기는 위의 그림과 같이 표기하고 그 의미는 객체지향언어 C++에서 사용되는 Template와 동일하다.
12. Utility
그림 11 - Utility Class
Utility class의 표기는 스테레오타입을 'utility'로 가진다. 그 의미는 일반적인 클래스의 의미가 아니라 프로그램의 편리를 위해 만들어진 클래스이다. 프로그램을 하면 반드시 Global로 만들어야 할 프로시져나 변수들이 존재하게 된다. 이를 기능적으로 분리하기 위해 utility class를 사용한다. Utility class 내부에 존재하는 attribute나 operation의 경우 Global 변수나 프로시져로 인식하면 된다.
13. MetaClass
MetaClass의 표기는 스테레오타입을 'metaclass'로 가지는 클래스이다. 이것은 metaclass의 인스턴스가 클래스가 되는 클래스를 의미한다.
14. Enumeration
Enumeration Class의 경우 스테레오타입을 'enumeration'으로 가지는 클래스이다. Enumeration Class의 의미는 프로그램언어에서 사용되는 일반적인 enumeration type과 의미가 유사하다. 정확한 Enumeration Class의 의미는 이 클래스의 인스턴스는 반드시 사용자가 정의한 특정 문자의 집합이어야 한다는 것이다. 이러한 문자는 상대적인 순서를 가지게 된다.
15. Stereotype
Stereotype Class의 경우 UML에서 사용되는 의미확장의 도구인 stereotype을 UML에서 지정한 것 이외에 사용자 정의 스테레오타입을 만들기위해 사용되는 클래스이다. Stereotype Class의 표기는 스테레오타입을 'stereotype'으로 가진다.
16. Class Pathname
클래스를 표기함에 있어서 UML에서 패키지(Package)를 같이 붙여 클래스의 범위를 지정할 수 있다. 패키지는 UML에서 Namespace역할을 한다. 패키지에 대한 자세한 설명은 차후 다이어그램에서 공통으로 사용되는 요소를 설명할 때 하기로 한다. 패키지속에 패키지가 포함 될 수 있으므로 패키지 path를 다 적용하여 클래스의 Pathname을 표기하기도 한다.
지금까지 클래스 다이어그램에서 정의하는 확장된 의미의 표기를 살펴보았다. 참고로 이러한 모든 내용에 대하여서 자세히 알고 싶다면 UML Spec을 보는 것이 도움이 될것이다.
실무에서는 시스템을 구성하는 클래스를 뽑아내고 그것의 역할을 지정하고 연관을 맺는 것이 가장 힘든 일일 것이다. 이것에 대한 정확히 정립된 방법은 존재하지 않는다. 약간이나마 정형화된 클래스를 뽑아내는 시점에 관하여 적어보면 통상 시스템 구축에 있어서 유스케이스 다이어그램을 그려서 시스템의 큰 기능을 만들고 그 유스케이스의 흐름을 가지고 시퀀스나 콜레버레이션 다이어그램에서 객체와 객체사이의 인터렉션을 정의하게 된다. 여기서 사용되는 객체의 행위와 속성을 가지고 클래스의 구체적 형상을 뽑아낼 수 있을 것이다. 물론 여러 번의 반복을 통한 클래스이 확정이 필요할 것이다.
'소프트웨어공학 > UML이야기' 카테고리의 다른 글
| 3. B Usecase Discription (0) | 2009.05.26 |
|---|---|
| 5. Sequence Diagram (1) | 2009.02.06 |
| 3. A. Usecase Diagram (0) | 2008.06.23 |
| 2. UML의 구성 (0) | 2008.06.16 |
| 1. UML이 무엇이며 왜 중요한가.? (0) | 2008.06.16 |
'사는 이야기 > 5dols story' 카테고리의 다른 글
| 공대생 이야기 (0) | 2008.10.26 |
|---|---|
| 공부를 시작한다는 것은. (0) | 2008.10.26 |
| 사람을 죽이는 법 (0) | 2008.10.25 |
| 잠 2번째 이야기 (0) | 2008.10.25 |
| 잠 (0) | 2008.10.25 |
'사는 이야기 > 5dols story' 카테고리의 다른 글
| 공부를 시작한다는 것은. (0) | 2008.10.26 |
|---|---|
| 어디선가 무슨일이 생기면 (0) | 2008.10.26 |
| 잠 2번째 이야기 (0) | 2008.10.25 |
| 잠 (0) | 2008.10.25 |
| 여자의 영향력 (0) | 2008.10.25 |
'사는 이야기 > 5dols story' 카테고리의 다른 글
| 어디선가 무슨일이 생기면 (0) | 2008.10.26 |
|---|---|
| 사람을 죽이는 법 (0) | 2008.10.25 |
| 잠 (0) | 2008.10.25 |
| 여자의 영향력 (0) | 2008.10.25 |
| 생일 (0) | 2008.10.25 |
'사는 이야기 > 5dols story' 카테고리의 다른 글
| 잠 2번째 이야기 (0) | 2008.10.25 |
|---|---|
| 잠 (0) | 2008.10.25 |
| 생일 (0) | 2008.10.25 |
| 이모티콘 (0) | 2008.10.25 |
| 호환마마보다 더 무서운 것 (0) | 2008.10.25 |
'사는 이야기 > 5dols story' 카테고리의 다른 글
| 잠 (0) | 2008.10.25 |
|---|---|
| 여자의 영향력 (0) | 2008.10.25 |
| 이모티콘 (0) | 2008.10.25 |
| 호환마마보다 더 무서운 것 (0) | 2008.10.25 |
| 삽질 (0) | 2008.10.25 |
'사는 이야기 > 5dols story' 카테고리의 다른 글
| 잠 (0) | 2008.10.25 |
|---|---|
| 여자의 영향력 (0) | 2008.10.25 |
| 생일 (0) | 2008.10.25 |
| 호환마마보다 더 무서운 것 (0) | 2008.10.25 |
| 삽질 (0) | 2008.10.25 |
'사는 이야기 > 5dols story' 카테고리의 다른 글
| 잠 (0) | 2008.10.25 |
|---|---|
| 여자의 영향력 (0) | 2008.10.25 |
| 생일 (0) | 2008.10.25 |
| 이모티콘 (0) | 2008.10.25 |
| 호환마마보다 더 무서운 것 (0) | 2008.10.25 |
아파치 2.0에선 Trace를 막는 건 쉬운데 사실 HEAD나 OPTIONS를 막는게 어떻게 하는지 몰라서
개삽질을 하다가 찾아냈다.
뭐 대략 서버에 다 막아버리는 방법은 다음과 같다.
DocumentRoot "/data2/htdocs"
이게 내 서버의 루트 디렉토리다. 루트디렉토리 다 때려막기는 다음과 같다.
<Directory "/data2/htdocs">
Options FollowSymLinks
AllowOverride None
<Limit GET POST>
Order allow,deny
Allow from all
</Limit>
<LimitExcept GET POST>
Require valid-user
</LimitExcept>
</Directory>
설명을 하자면 디렉토리를 설정한 후
대략 GET POST를 제외한 모든 녀석은 막아버리고
만약 그 외 OPTIONS나 HEAD 등을 사용하려면 Valid-user만 가능하다는 뜻인데..
가디언 TFT 최세환님이 말해주셨는데... 젝일 까먹었다..T.T
설명을 하자면 디렉토리를 설정한 후
대략 GET POST를 제외한 모든 녀석은 막아버리고
만약 그 외 OPTIONS나 HEAD 등을 사용하려면 Valid-user만 가능하다는 뜻인데..
가디언 TFT 최세환님이 말해주셨는데... 젝일 까먹었다..T.T
'서버 이야기 > 웹서버 설정' 카테고리의 다른 글
| Apache Log에 I/O byte 나오게 하기 (0) | 2009.10.07 |
|---|---|
| jconsol 사용하기 (1) | 2009.08.03 |
| 아파치 웹서버 모니터링하기 (0) | 2008.10.06 |
| 아파치 로그 날짜 별로 남기기 (0) | 2008.09.26 |
| Virtual Host 안쓰고 도메인 Rewrite하기 (0) | 2008.09.25 |
이건 내가 대학교 2학년 때 프로젝트로 제출 했던 도서관 요구사항 정의 Doc이다.
요구사항 정의는 IEEE standard 의 기본을 따랐다. 안에는 웃기긴 하지만 시나리오도 같이 정의 되어있다.
만약에 누군가 받아간다면 아주 아주 소프트웨어 공학을 공부하는데 유용한 자료가 될 듯 하다.
그리고 수준이 딱 대학교 2학년 수준이라 각 항목마다 다를 수
목차는 다음과 같다.
Table of Contents. 3
1.0 Purpose. 4
1.1 Introduction. 4
1.2 Scope. 4
1.3 Glossary. 4
1.4 Team Member 4
1.5 References 4
2.0. General Description. 4
2.1. Product Functions 4
2.2. User Characteristics 5
2.3. Constraints 5
2.4. Basic Scenario. 5
3.0 Specific requirements 7
3.1 Explanation of category ID and Inscription rule. 7
3.2 Functional requirements 7
3.2.1 Functional requirements definitions 7
3.2.2 The core functional requirements deduce. 7
3.2.3 Functional requirements table. 8
3.3 Non-functional requirements table. 9
3.3.1 Non-functional requirements definitions 9
3.3.2 Non-functional requirements 9
3.4 Use cases modeling. 11
3.4.1 System use cases 11
3.4.2 Use cases summary. 11
3.4.3 Detail Use cases scenario. 12
3.5 Information Level Designed. 21
3.5.1 Well Formed. 21
3.5.2 Requirement Tracking Document 21
3.5.3DBDL. 22
4.0 External interface requirements 26
4.1 User Interfaces 26
4.2 Hardware Interfaces 26
4.3 Software Interfaces 26
4.4 Communication Interfaces 26
'소프트웨어공학 > 산출물 정리' 카테고리의 다른 글
| Food website Project SPMP (Software Project Management Plan) (0) | 2008.10.26 |
|---|---|
| Food website Project SRS (Software Requirements Specification) - IEEE standard (1) | 2008.10.26 |
| Food website Project (Proposal) (0) | 2008.10.26 |
| Library Project SPDD (Software Project Database Design) (0) | 2008.10.26 |
| IEEE Standard for Software Unit Testing (0) | 2008.06.12 |
아파치웹서버를 동작시킨 후에 관리자는 서버의 부하를 어느정도 받고 있는지 모니터링을 해야한다. 부하가 많고 응답속도가 현저하게 떨어졌을 때에는 적절한 조치를 취해야하며, 데몬은 떠있지만 제대로 응답하지 않는 경우도 있기 때문에 항상 모니터링을 해야한다. 아파치웹서버의 모니터링은 유닉스의 쉘상태에서도 할 수 있으며, 웹으로도 할 수 있다.
일단 이런 모니터링을 가능하게 하려면 httpd.conf파일에 다음과 같이 설정을 해야한다.
[아파치 모니터링을 위하여 httpd.conf의 설정] : 특정 IP주소자만 허용
| <Location /server-status> SetHandler server-status Order deny,allow Deny from all Allow from 192.168.0.203 </Location> |
위의 예와 같이 아파치 모니터링을 위해서는 httpd.conf 파일내에 server-status 설정이 되어 있어야 한다. 위의 설정에서 Order deny, allow 와 Deny from all 그리고 Allow from 192.168.0.203 설정으로 인하여 이 모니터링페이지를 웹브라우저로 확인가능한 곳은 192.168.0.203 IP 사용자만 가능하다. 당연히 192.168.0.203 사용자는 아파치웹서버의 관리자일 것이다.
만약 특정 IP 주소가 아닌 네트워크로 지정하고자 한다면 다음과 같이 하면 된다.
[아파치 모니터링을 위하여 httpd.conf의 설정] : 특정 네트워크 사용자 모드 허용
| <Location /server-status> SetHandler server-status Order deny,allow Deny from all Allow from 192.168.0.0/24 </Location> |
즉, 192.168.0.0번 IP 사용자부터 192.168.0.255 사용자까지만 모니터링페이지를 로딩할 수 있다는 의미이다. 위의 설정은 관리자에 소속된 사용자들만 접속을 허용하기 위한 설정이라고 생각하면 된다.
이제 서버모니터링을 웹브라우저로 해보자. 먼저 아파치를 재시작시켜야 한다.
http://192.168.0.201/server-status
또한 주기적인 갱신으로 계속적인 모니터링을 하려면 다음과 같이 refresh 주기를 주면 된다. 단위는 초이다.
http://192.168.0.201/server-status?refresh=5
이 부분에 대한 대략적인 설명은 다음과 같다.
- Server Version : 아파치서버의 버전을 나타낸다.
- Server Built : 아파치서버가 설치된 년, 월, 일, 시
- Current Time : 현재 모니터링하는 년, 월, 일, 요일, 시간
- Restart Time : 아파치서버가 재동작한 년, 월, 일, 요일, 시간
- Parent Server Generation : 서버 부하방지을 위한 아파치서버 생성갯수 총서버 개수중 요구에 응하고 있는 서버의 개수와 놀고 있는 서버의 개수 Scoreboard Key 에 대한 정보
- "-" : 응답을 하기 위해 대기중임을 나타냄.
- "S" : 시작되고 있음을 나타냄.
- "R" : 응답을 위해 요구사항을 해석하고 있음.
- "L" : 요구에 대한 응답을 하고 있음.
- "K" : 계속연결중임.
- "D" : DNS서버에 요구도메인 검색중임.
- PID key : 프로세스정보를 보여준다.
'서버 이야기 > 웹서버 설정' 카테고리의 다른 글
| Apache Log에 I/O byte 나오게 하기 (0) | 2009.10.07 |
|---|---|
| jconsol 사용하기 (1) | 2009.08.03 |
| XST 취약성 관련 GET, POST 외에 죄다 막아버리기 (0) | 2008.10.20 |
| 아파치 로그 날짜 별로 남기기 (0) | 2008.09.26 |
| Virtual Host 안쓰고 도메인 Rewrite하기 (0) | 2008.09.25 |
인터넷 페이지 오류들 인터넷 페이지 오류들
어딘가에서 스크랩 한 글..;; 어디서 했는지 기억이 안나..
▶ 403 Forbidden/Access Denied (403 금지/액세스 거부)
이 웹 사이트는 패스워드와 같은 특별한 액세스 승인을 필요로 하는 경우입니다.
▶ 404 Not Found (404 찾을 수 없음)
브라우저가 호스트 컴퓨터는 찾았으나 요청된 특정 도큐먼트를 찾지 못한 경우입니다.
정확한 주소를 입력했는지 확인해 봅니다. 그 페이지는 해당 웹 사이트에서 제거되었을 수도 있고 위치가 바뀌었을 수도 있습니다.
파일명을 떼어내고 주소를 다시 한 번 입력해 봅니다. 즉, 한 단계 위의 웹 사이트를 찾아 봅니다.
▶ 503 Service Unavailable (503 서비스 불가)
해당 웹 사이트의 서버에 과부하가 걸린 경우입니다.
몇 초 후에 다시 시도해 봅니다.
▶ Bad file request (잘못된 파일 요청)
온라인 폼 또는 HTML 코드가 잘못된 경우입니다.
▶ Connection refused by host (호스트의 접속 거부)
위에 있는 ‘403 Forbidden/Access Denied’ 에러와 유사한 상황입니다.
▶ Failed DNS lookup (DNS 찾기 실패)
해당 웹 사이트의 URL이 적절한 IP 주소로 전환될 수 없는 경우입니다.
이런 에러는 상용 사이트에서 빈번하게 발생하는데 IP 주소 전환을 담당하는 컴퓨터들이 과부하 상태에 놓이기 때문이라고 합니다.
물론, 주소를 잘못 입력한 경우에도 발생할 수 있습니다.
주소를 다시 한 번 입력해 보거나, 혼잡하지 않을 것 같은 시간에 다시 시도해 봅니다.
▶ Helper application not found
보조 응용프로그램(helper application)을 필요로 하는 파일을 다운받으려 하는데, 인터넷 익스플로러가 찾지 못하는 경우입니다.
이런 경우에는 아무 Windows 창이나 열어서 ‘보기(V)’의 ‘폴더 옵션(O)’에 있는 ‘파일 형식’ 탭을 선택하여 보조 응용프로그램을 위한 디렉토리 및 파일명이 정확하게 입력되도록 합니다.
▶ Not found (찾을 수 없음)
하이퍼링크가 가리키는 웹 페이지가 더 이상 존재하지 않음을 나타냅니다.
▶ Site unavailable (사이트 사용 불가)
너무 많은 사람들이 동시에 액세스하려 하면 온라인상에 노이즈가 생겨 해당 사이트가 다운될 수도 있고, 아니면 더 이상 그 사이트가 존재하지 않는 경우일 수도 있습니다.
주소를 잘못 입력해도 나올 수 있습니다.
▶ 각 Error 코드별 의미
100 : Continue
101 : Switching protocols
200 : OK, 에러없이 전송 성공
201 : Created, POST 명령 실행 및 성공
202 : Accepted, 서버가 클라이언트 명령을 받음
203 : Non-authoritative information, 서버가 클라이언트 요구 중 일부 만 전송
204 : No content, 클라언트 요구을 처리했으나 전송할 데이터가 없음
205 : Reset content
206 : Partial content
300 : Multiple choices, 최근에 옮겨진 데이터를 요청
301 : Moved permanently, 요구한 데이터를 변경된 임시 URL에서 찾았음
302 : Moved temporarily, 요구한 데이터가 변경된 URL에 있음을 명시
303 : See other, 요구한 데이터를 변경하지 않았기 때문에 문제가 있음
304 : Not modified
305 : Use proxy
400 : Bad request, 클라이언트의 잘못된 요청으로 처리할 수 없음
401 : Unauthorized, 클라이언트의 인증 실패
402 : Payment required, 예약됨
403 : Forbidden, 접근이 거부된 문서를 요청함
404 : Not found, 문서를 찾을 수 없음
405 : Method not allowed, 리소스를 허용안함
406 : Not acceptable, 허용할 수 없음
407 : Proxy authentication required, 프록시 인증 필요
408 : Request timeout, 요청시간이 지남
409 : Conflict
410 : Gone, 영구적으로 사용할 수 없음
411 : Length required
412 : Precondition failed, 전체조건 실패
413 : Request entity too large,
414 : Request-URI too long, URL이 너무 김
415 : Unsupported media type
500 : Internal server error, 내부서버 오류(잘못된 스크립트 실행시)
501 : Not implemented, 클라이언트에서 서버가 수행할 수 없는 행동을 요구함
502 : Bad gateway, 서버의 과부하 상태
503 : Service unavailable, 외부 서비스가 죽었거나 현재 멈춤 상태
504 : Gateway timeout
505 : HTTP version not supported
507 : 짜라가 로그인 했습니다. 똘끼를 피하려면 컴퓨터를 꺼주세요..
지금 나는 302의 에러와 싸우고 있다..-0-;;
이녀석의 302는 아무래도 액션단 안에 리다이렉트 되는 부분이 있으면 나는 에러인 것 같다..--;; 물론 아직 웹에 관련된 지식이 많지 않아 확인은 못했다는..;;
어딘가에서 스크랩 한 글..;; 어디서 했는지 기억이 안나..
▶ 403 Forbidden/Access Denied (403 금지/액세스 거부)
이 웹 사이트는 패스워드와 같은 특별한 액세스 승인을 필요로 하는 경우입니다.
▶ 404 Not Found (404 찾을 수 없음)
브라우저가 호스트 컴퓨터는 찾았으나 요청된 특정 도큐먼트를 찾지 못한 경우입니다.
정확한 주소를 입력했는지 확인해 봅니다. 그 페이지는 해당 웹 사이트에서 제거되었을 수도 있고 위치가 바뀌었을 수도 있습니다.
파일명을 떼어내고 주소를 다시 한 번 입력해 봅니다. 즉, 한 단계 위의 웹 사이트를 찾아 봅니다.
▶ 503 Service Unavailable (503 서비스 불가)
해당 웹 사이트의 서버에 과부하가 걸린 경우입니다.
몇 초 후에 다시 시도해 봅니다.
▶ Bad file request (잘못된 파일 요청)
온라인 폼 또는 HTML 코드가 잘못된 경우입니다.
▶ Connection refused by host (호스트의 접속 거부)
위에 있는 ‘403 Forbidden/Access Denied’ 에러와 유사한 상황입니다.
▶ Failed DNS lookup (DNS 찾기 실패)
해당 웹 사이트의 URL이 적절한 IP 주소로 전환될 수 없는 경우입니다.
이런 에러는 상용 사이트에서 빈번하게 발생하는데 IP 주소 전환을 담당하는 컴퓨터들이 과부하 상태에 놓이기 때문이라고 합니다.
물론, 주소를 잘못 입력한 경우에도 발생할 수 있습니다.
주소를 다시 한 번 입력해 보거나, 혼잡하지 않을 것 같은 시간에 다시 시도해 봅니다.
▶ Helper application not found
보조 응용프로그램(helper application)을 필요로 하는 파일을 다운받으려 하는데, 인터넷 익스플로러가 찾지 못하는 경우입니다.
이런 경우에는 아무 Windows 창이나 열어서 ‘보기(V)’의 ‘폴더 옵션(O)’에 있는 ‘파일 형식’ 탭을 선택하여 보조 응용프로그램을 위한 디렉토리 및 파일명이 정확하게 입력되도록 합니다.
▶ Not found (찾을 수 없음)
하이퍼링크가 가리키는 웹 페이지가 더 이상 존재하지 않음을 나타냅니다.
▶ Site unavailable (사이트 사용 불가)
너무 많은 사람들이 동시에 액세스하려 하면 온라인상에 노이즈가 생겨 해당 사이트가 다운될 수도 있고, 아니면 더 이상 그 사이트가 존재하지 않는 경우일 수도 있습니다.
주소를 잘못 입력해도 나올 수 있습니다.
▶ 각 Error 코드별 의미
100 : Continue
101 : Switching protocols
200 : OK, 에러없이 전송 성공
201 : Created, POST 명령 실행 및 성공
202 : Accepted, 서버가 클라이언트 명령을 받음
203 : Non-authoritative information, 서버가 클라이언트 요구 중 일부 만 전송
204 : No content, 클라언트 요구을 처리했으나 전송할 데이터가 없음
205 : Reset content
206 : Partial content
300 : Multiple choices, 최근에 옮겨진 데이터를 요청
301 : Moved permanently, 요구한 데이터를 변경된 임시 URL에서 찾았음
302 : Moved temporarily, 요구한 데이터가 변경된 URL에 있음을 명시
303 : See other, 요구한 데이터를 변경하지 않았기 때문에 문제가 있음
304 : Not modified
305 : Use proxy
400 : Bad request, 클라이언트의 잘못된 요청으로 처리할 수 없음
401 : Unauthorized, 클라이언트의 인증 실패
402 : Payment required, 예약됨
403 : Forbidden, 접근이 거부된 문서를 요청함
404 : Not found, 문서를 찾을 수 없음
405 : Method not allowed, 리소스를 허용안함
406 : Not acceptable, 허용할 수 없음
407 : Proxy authentication required, 프록시 인증 필요
408 : Request timeout, 요청시간이 지남
409 : Conflict
410 : Gone, 영구적으로 사용할 수 없음
411 : Length required
412 : Precondition failed, 전체조건 실패
413 : Request entity too large,
414 : Request-URI too long, URL이 너무 김
415 : Unsupported media type
500 : Internal server error, 내부서버 오류(잘못된 스크립트 실행시)
501 : Not implemented, 클라이언트에서 서버가 수행할 수 없는 행동을 요구함
502 : Bad gateway, 서버의 과부하 상태
503 : Service unavailable, 외부 서비스가 죽었거나 현재 멈춤 상태
504 : Gateway timeout
505 : HTTP version not supported
507 : 짜라가 로그인 했습니다. 똘끼를 피하려면 컴퓨터를 꺼주세요..
지금 나는 302의 에러와 싸우고 있다..-0-;;
이녀석의 302는 아무래도 액션단 안에 리다이렉트 되는 부분이 있으면 나는 에러인 것 같다..--;; 물론 아직 웹에 관련된 지식이 많지 않아 확인은 못했다는..;;
