노는 게 제일 좋아

기본 User Interface를 알아보고 정말 간단하게 클래스 다이어그램을 작성하는 법만 알아보자 !!정말 간단하게 1번: Class 포함 모든 것들을 만들 수 있는 TOOL BOX 누르고 워크스페이스(2번)에 올려놓기만 하면 된다 2번: workspace 정말 우리가 다이어그램을 그리는 곳이다. 3번: 각 컴포넌트들의 세부사항 조정하는 곳이다. 저기서 multiplicity도 설정할 수 있다. 4번: 클래스에 마우스를 대고 우클릭을 하면 모든 것이 가능하다 attribute, operation 추가도 가능하고 이름도 바꾸고 맘대로 다한다. 이것은 정말 기본적인 것으로 맛보기만 하려고 살짝 건드려봤다. 시퀀스도 살짝 건드리자 저기서 우클릭해서 add diagram에서 시퀀스 다이어그램을 만들자 우측에서..

그렇다. 이제 모델링을 배워봤는데 모델링을 어떻게 하느냐? 궁금할 것이다 IBM의 Rational Modeler, 마이크로소프트의 Visio, ArgoUML, StarUML, NetBeans UML 플러그인 등이 있으니 쓰고 싶은거 쓰면 된다. 물론 나는 starUML 쓸 거다 ㅎㅎ 이렇게 생겼다. UML도구는 왜쓰느냐?? 3가지 이유로 쓴다. UML 도구의 기능 1. 프로젝트 관리 • 다이어그램과 코드를 모델별로 그루핑하여 프로젝트 별로 보관하고 불러냄 • 서브시스템이나 패키지별로 그루핑 • 프로젝트의 내용은 주로 하나의 파일로 관리하지만 여러 팀으로 나누어 작업하기 위하여 유닛별로 쪼개어 관리 2. 코드 및 문서 생성 • 사용자가 템플릿을 정의하고 템플릿을 이용하여 문서를 일괄 생성 • StarUML..

이번엔 상태 다이어그램과 액티비티 다이어그램을 알아볼 것이다. 한 번 배워보자 우선 상태 다이어그램부터 배워보자 상태 다이어그램은 객체가 가질 수 있는 가능한 상태들과 그 변화를 나타낸 것으로 외부 이벤트에 의한 자극에 대하여 객체들의 반응할 때 어떻게 상태의 변화가 일어나는지를 모델링 한 것이다. 다시 이벤트와 상태를 설명하겠다. 이벤트 : 서브시스템 또는 객체나 컴포넌트에 대하여 요청이나 관심이 일어난 것 상태 : 이벤트의 발생으로 들어가거나 빠져 나오게 되는 서브시스템 또는 객체의 조건을 추상적으로 이름 붙여 놓은 것 **UML을 이용하기 전에 미리 서브시스템이나 객체가 어떤 상태를 가질 수 있는지, 또한 그런 상태에 들어가게 하는 조건, 즉 외부 이벤트나 오퍼레이션이 무엇인지 파악해야 한다. **..

이번에는 동적 모델링에 대해서 알아보려고 한다. 동적 모델링이란 클래스들의 상호작용이나 클래스의 상태 변화 등 시스템 내부의 동작을 모델링하는 것을 말한다. 동적 모델에는 3가지 다이어그램이 있다. 1. 인터랙션 다이어그램 2. 상태 다이어그램 3. 액티비티 다이어그램 인터랙션 다이어그램은 사용 사례를 실현시키기 위하여 내부 클래스들이 어떻게 협동하는지 나타낸다. 인터랙션 다이어그램도 2가지 종류가 있다. 객체를 울타리 형태로 나열하고 이벤트의 발생 순서에 초점을 두고 위에서 아래로 명시하는 타입을 시퀀스 다이어그램이라 한다. 클래스를 네트워크 형태로 배치하고 객체 사이에 어떤 메세지 교환이 이루어지는지를 중점적으로 표시하는 방법이 커뮤니케이션 다이어그램이라고 한다. 2가지는 이름하고 표현 방식만 다르고..

전에 이어서 정적 모델링을 위한 클래스 다이어그램을 작성하려고 한다. 심볼, 규정, 규칙들을 알아봤으니까 이제 실전이다 모델링 할 때 순서없이 생각나는 대로 작업하면 당연히 품질 하락. 노동력 상승의 결과를 낳을 것이다. 그러면 순서를 정하고 작업을 시작해야 한다는 얘기다. 클래스 다이어그램 작성 순서를 알아보자 1. 클래스가 될 만한 후보를 파악 도메인 분석할 때 개념을 장 정리해야 클래스를 쉽게 찾을 수 있다. ++요구 추출 시 사용한 자료들에서도 발견할 수 있다, 2. 가장 중요한 클래스를 시작으로 연관, 상속, 속성을 추가 유사한 클래스를 묶어서 슈퍼클래스를 생성하거나 복잡한 클래스를 나누어서 서브클래스를 생성하는 방법이 있다. 각각 상향식, 하향식 관계라고 부른다. 3. 클래스의 주요 임무(re..

이제야 정말 UML로 모델링을 해보려고 한다. UML에 대해서 알아보자 UML이란 Unified Modeling Language로 객체지향 모델을 표현하는 방법 중 하나이다. 다시 말하면 객체지향 소프트웨어를 모델링 하는 표준 그래픽 언어라고 할 수 있다. ++UML은 객체지향 설계 표현방법의 표준으로 알려져있다. UML은 시스템의 설계 뿐만 아니라 시스템의 여러가지 측면을 모델링하여 나타낼 수 있다. 클래스를 상세히 기술하는 것만은 이해하기 충분하지 않다. 모델링으로 여러 클래스가 어떻게 연관되어 있고 필요한 기능을 제공하기 위하여 어떻게 상호작용 하는지 이해할 수 있다. UML은 이를 가능케 한다. 위의 그림처럼 표현하는 방식이다. 그렇다면 저 오른쪽 UML 그림은 뭘까? 역시 그림이 제일 이해하기 ..

계획 다 했으니 이제 정말로 형태를 갖춰가는 작업을 해야지?? 그게 모델링이다. 형태를 만드는 것 모델링이란 도메인 지식을 체계화 하는 과정으로 중요한 도메인 개념과 특성, 관계를 파악하여 다이어그램으로 정형화하는 것이다. 모델링은 개발팀이 응용 문제를 이해하는 데 도움을 주는 일종의 개념화 과정이다. 요구 추출과정에 의하여 수집된 도메인 개념과 정보는 분석되고 분류되어 UML과 같은 방법을 이용하여 모델로 비주얼화 된다. 모델링이 구체적으로 어떻게 개발자에게 도움을 주느냐? 1. 응용문제를 이해하는 데 도움을 줌 2. 개발팀원들 사이에 응용문제의 공통 개념으로 대화하게 하고 개선시킴 3. 파악한 개념을 사용자와 고객에게 전달 할 때 도움을 줌 4. 후속 작업 즉 설계, 구현, 테스팅, 유지보수에 개념적..

도메인 분석은 문제의 배경을 알고자 하는 것이다. 또한 도메인은 시스템을 모델링하기 위한 개념적 프레임워크를 제공한다고 했다. 다시 말해서 도메인 분석 자체는 모델을 만드는 것은 아니다. 모델링을 위한 개념 이해화 정보 추출 작업일 뿐이었다. 우리는 모델링 하기 전 단계인 사용사례와 액터를 알아봐야 한다. 사용 사례란 시스템이 수행할 것으로 기대되는 기능을 말한다. 시스템 사용자에게 서비스를 제공하기 위한 상호작용의 단위로도 쓰인다. 다시 말해서 사용자 또는 외부 시스템이나 기타 요소들이 시스템과 상호작용 하는 다이얼로그를 모델링 한 것이다. ex) 현금인출기의 현금 인출 시스템과 주고 받는 이벤트의 기록 == 사용사례 사용사례는 사용자와 시스템 설계자/테스트 프로그래머들이 의사 교환하는데 유용하게 쓰인..

요구분석을 살짝 맛봤다 근데 항상 중요한게 문제도 중요하지만 문제가 생기게 된 배경을 아는 것도 중요하다 그래서 도메인에 대해서 알아보려고 한다. 도메인이란 간단히 말해서 요구의 배경을 말한다. 소프트웨어를 구축할 때 문제 자체도 중요하지만 문제가 어디에 놓여있는가도 중요하다. 즉 문제의 배경을 말한다. 도메인을 분석하는 이유는 설계 모델링에 필요한 여러 개념과 비즈니스 파악을 위함이다. 이러한 사항을 깊이 이해하지 않고서는 제대로 된 설계를 할 수 없다. 도메인 분석에서는 응용 분야에 존재하는 개념을 잘 정의하고 분석해서 시스템에 존재하는 개념으로 정립하는 단계 다시 말해서 도메인 분석이란 요구의 배경을 이해해서 개발될 시스템을 설명하는 개념을 발견하는 과정이다. 그래서 앞서 문제의 범위를 정했듯이 여..

요구 분석 단계의 전반적인 측면을 알았다면 요구 추출에 대해서 알아보자 요구 추출이란 소프트웨어 개발에서 특별히 중요한 작업으로 사용자가 무엇은 원하는지 결정을 내리는 작업이며 여러가지 기법을 통해서 얻어진다. 요구 추출에는 세 가지 단계의 작업이 필요하다 1. 응용에 대한 정보 출처 파악 2. 응용에 대한 정보 취합 3. 요구와 제한 사항의 정의 요구 추출은 응용 분야에 대한 정보를 모으는 것부터 시작된다. 그러한 요구 추출을 위한 정보를 모으는 방법 또한 여러가지다. 고객의 발표 문헌 조사 업무 절차와 양식 조사 관련자들 설문지 사용자와의 인터뷰 브레인 스토밍 회의 사용 스토리 또는 사용사례 작성 위 방법을 통해서 정보를 모은다. ++위 방법을 통해서 얻은 요구는 우선순위로 나누면 좋다. 1. 절대적..