Software Design - 원칙을 세우고, 개념을 설정하고 이걸 실행하는 디자인을 소프트웨어 디자인이라 한다. 이런 소프트웨어 디자인은 최고 품질의 시스템과 제품을 생산할 수 있어야 한다. - 디자인 컨셉은 디자인대로 생산을 하기전에 무조건적으로 이해가 되어있어야 한다. - 소프트웨어 디자인을 실행하는 기술이나 기법은 언제든지 바뀔 수 있다. 새로운 기술이나 분석기술, 소프트웨어에 대한 새로운 이해가 이뤄졌을 때 바뀐다. Software Engineering Design - Data/Class Design – 분석 클래스(analysis classes)를 구현 클래스 (implementation classes)와 데이터 구조로 만든다. 분석 클래스 : 목적, 속성, 다른 클래스와의 관계가 담긴다. ..

보다 다양한 다이어그램에 대한 설명이 기술된다. Activity Diagram Swimlane Diagrams - Swimlane Diagram은 UML의 Activity Diagram을 유용하게 변형한 것이다. use case를 flow에 따라 activity을 단계별로 나누어 표현하는 방식이다. - 하나의 use case에 여러 Actor가 관여할 수 있다. 이 때 Actor에 따라서 어떤 Activity가 진행되고 있는지를 표시할 수 있어야 한다. 또는 analysis class가 있다면 해당 클래스의 액션의 역할에 대해 Activity Rectangle에 기재할 수 있어야 한다. - Lane이 여러 개가 있다면 각 lane이 Actor가 되고, Lane에 수직으로 이어지는 segments(Acti..

지난 정리에 이어 Class-Based Modeling에 대해 서술한다. Defining Attributes - 클래스 다이어그램에서 클래스를 정의하고, Attributes를 정의하는 단계 - 클래스가 모델에 필요한 이유와 역할을 표현하는데 사용된다. - 의미 있는 여러 attributes를 analysis class에 포함시켜야 하는데, 이 때 use case를 잘 구분하고 명확하게 설명할 수 있을 정도로 탐색해야 한다. - 문제상황을 완벽하게 표현할 수 있는 attributes(composite and/or elementary)를 명시해야 한다. Defining Operations - Operations은 object의 행동을 정의한다. - Operations은 크게 4가지 종류로 나뉜다. 데이터를 ..

유저 케이스에 What to Write About? (무엇을 쓸 것인가?) - Requirements Engineering의 두 산출물 {inception, elicitation}을 적는다. 이 둘은 use cases를 작성하는데 필요한 정보를 제공할 것이다. - Use cases를 개발 시작할 때, 특정한 actor가 활동을 진행하는데 필요한 함수 목록을 적어야 한다. - Required system functions은 stakeholders 간의 대화를 통해서, activity diagram 으로부터 얻을 수 있다. (activity diagram은 시스템이 수행하는 작업을 나열해 놓은 diagram이다.) - 이런 형식의 use cases는 primary scenarios 라고 불린다. Altern..

Requirement Analysis - 성격 소프트웨어의 기능과 행동을 분명하게 표시해야 한다. 다른 소프트웨어 요소와의 인터페이스를 명확하게 보여줘야 한다. 소프트웨어가 반드시 가지게 될 제한사항을 제시해야 한다. - 소프트웨어 엔지니어가 요구사항 분석을 위해 해야 할 일 일찍이 작성된 추상적인 basic 요구사항을 펼쳐보아야 한다. 유저의 다양한 관점에서 필요한 요구사항을 확인하고, 이를 모델화해야 한다. Requirement Models (요구사항 모델) 표현법 (구체화하는 방법) - Scenario-based models : 시스템 내 다양한 Actor의 관점에서 필요한 요구사항을 그려낸다. - Class-oriented models : object-oriented 된 클래스로 표현하는 방법이다..

UML Use Case Diagram - Scenario Based Analysis에 속하는 Diagram 이다. - Actor : 시스템과 소통하는 내부에 있는 모든 요소 Negotiating Requirements(요구사항 협상) - 협상 결과가 stakeholder 모두에게 ‘win-win’한 결과가 나와야 한다. Stakeholder는 만족스러운 결과물을 얻고, developers는 deadline에 맞춰 생산하는 것이 ‘win-win’ 이다. 이런 결과를 만드는 건 Handshaking 이 거의 유일하다. - Developers가 요구사항을 분석하고 솔루션을 제시한다. 이 때 묘사하는 것은 효과와, Developer가 솔루션을 구상하며 가진 생각이다. - Customer는 솔루션을 분석하고, 놓..