2.log

생성 패턴 객체 생성과 관련, 객체의 인스턴스화 과정을 추상화하는 방법 다룸, 캡슐화를 통해 정보 은닉하여 재사용과 유연성 높임 Factory Method Pattern (Virtual Constructor) 객체 생성을 위한 인터페이스는 정의하지만, 어떤 클래스의 인스턴스를 생성할지에 대한 결정은 서브클래스에 위임함으로써 객체 생성로직을 캡슐화하는 패턴으로, 생성할 객체 타입이 예측불가할 때 사용가능 + OCP(Open-Closed-Principle) 적용 + 기존 클라이언트 코드 수정 없이 새로운 인스턴스를 다른 방법으로 생성 가능 (유연성, 확장성) + 변화가 일어날 수 있는 객체 생성을 담당하는 클래스(Factory)를 만들어 한 곳에서 관리 (유지보수 용이) + 객체 생성로직을 캡슐화하고, 구체..

디자인 패턴 '이럴 때에는 이런 방식을 사용하면 좋다'라고 선배 개발자들이 경험적으로 정립해 놓은 좋은 설계들의 모음 가장 대표적인 것이 GoF(Gang of Four)의 23가지 패턴으로, 디자인 패턴을 잘 알면 장황하게 설명할 필요 없이 '싱글톤 사용할 겁니다' 한 마디로 상대에게 의도한 바를 명확히 전달할 수 있고, 설계과정에서 겪는 시행착오를 줄일 수 있어 의사소통과 생산성 향상에 도움을 줌 (단, 패턴!= 진리) 패턴의 분류 생성패턴은 객체의 생성, 구조패턴은 객체 간 합성, 행위패턴은 객체 간 상호작용에 관여 클래스 패턴은 주로 상속을 통해 관련되는 클래스와 서브클래스 간의 관련성을 다룸 / 컴파일 타임에 정적으로 결정 객체 패턴은 객체 간 관련성을 다룸 / 런타임에 동적으로 결정 생성 패턴 ..

핵심은 '사용자가 사용하기 쉽고 그들이 예상한 대로 동작' 하게 하는 것 리눅스 커맨드의 경우 철자 하나 잘못 쓰면 다 다시 써야 하고 작업이 수행되고 있는지 상태출력 역시 옵션으로 부여해야 함 일반 사용자 입장에서는 작업이 처리가 되고 있는건지 알 수가 없고 수정도 불편한 좋지 못한 디자인이라 할 수 있음 그리고 향후 프로젝트 할 때에 사이트를 하나 만들게 될 터인데 제공할 서비스가 기존에 이미 존재하여 사용자가 이미 거기 익숙해져 있을 경우 그러한 대형 사이트와 유사한 구조를 가지고 가야 사용자가 내 사이트에서도 방황하지 않고 쉽게 적응할 수 있음 또한 요즘에는 웹이라도 모바일 환경에서 접속하는 경우가 많기에 오늘은 실질적으로 도움이 될 만한 현업 디자이너분의 설명을 간략히 정리하고 마치려 함 기본적..

* KOWC에 등록된 동국대학교 최은만 교수님의 강의내용을 공부목적으로 정리한 글임을 밝힙니다. | 출처 : http://www.kocw.net/home/search/kemView.do?kemId=331697&ar=relateCourse 소프트웨어 아키텍처 소프트웨어의 일관된 모양, 구조, 스타일을 정하는 작업으로, 일단 시스템이 한 번 개발된 뒤에는 잚 못된 구조를 바로잡기 쉽지 않기에 초기에 이를 잘 정립해 둠으로써 이해관계자들의 소통과 추후 발생할 수정 및 유지보수를 용이하게 할 수 있음 범위 시스템 분할, 전체 제어 흐름, 오류 처리 방침, 서브시스템 간 프로토콜 등 Design Stamina Hypothesis 디자인을 고려하지 않은 소프트웨어의 경우 디자인 활동에 시간을 쏟지 않는 초반부에는 ..

* KOWC에 등록된 동국대학교 최은만 교수님의 강의내용을 공부목적으로 정리한 글임을 밝힙니다. | 출처 : http://www.kocw.net/home/search/kemView.do?kemId=331697&ar=relateCourse 분석과 설계 비교 소프트웨어 설계 아키텍처 설계 시스템 컴포넌트와 이들의 커넥션에 초점 (모듈의 역할과 인터페이스 정의) 상세설계 코드 수준에 가까움 (모듈 내부 알고리즘, 데이터 명세화) 좋은 설계의 요건 1. 복잡성 최소화 2. 느슨한 결합(Loose coupling0 3. 강한 응집력(Strong cohension) 4. 확장성 5. 재사용성 6. 유지보수성 7. 유연성 >> 궁금 목표 : 모듈화, 캡슐화 등을 통해 결합성은 낮추고 응집력은 높여 복잡성을 최소화하는..

* KOWC에 등록된 동국대학교 최은만 교수님의 강의내용을 공부목적으로 정리한 글임을 밝힙니다. | 출처 : http://www.kocw.net/home/search/kemView.do?kemId=331697&ar=relateCourse Sequence Diagram Use Case에 나타난 객체들 간의 상호작용을 표현한 것 (다양한 View의 시나리오 표현 가능, Use Case 보조) 어떤 메시지가 언제 보내지는지 수행순서를 시간 흐름에 따라 나타내어 시스템의 동적 측면 보여줌 (Dynamic View) 구성요소 Object Life Line 모델링되는 인스턴스 나타냄 박스와 점선으로 이루어지며, 아래로 내려갈수록 시간 경과 Activation (box) Life Line의 인스턴스가 다른 인스턴스와..

* KOWC에 등록된 동국대학교 최은만 교수님의 강의내용을 공부목적으로 정리한 글임을 밝힙니다. | 출처 : http://www.kocw.net/home/search/kemView.do?kemId=331697&ar=relateCourse 전통적 분석기법과 객체지향의 차이 전통적 기법의 프로그램은 '처리(process)' 순서, 절차에 초점을 맞추어 프로그램이 데이터와 그러한 데이터를 조작하기 위한 함수들로 구성됨. 이때 데이터(자료)와 함수가 분리된 채 함수 간 데이터를 주고받다 보니 상호 간의 높은 의존성과 복잡성, 불필요한 중복, 낮은 재사용성 문제를 야기하며 프로그램 효율성/생산성 떨어뜨리게 됨 객체지향은 이러한 문제를 해결하기 위해 등장한 방법론으로, 전통적 기법의 프로그램이 함수의 집합체였다면,..

* KOWC에 등록된 동국대학교 최은만 교수님의 강의내용을 공부목적으로 정리한 글임을 밝힙니다. | 출처 : http://www.kocw.net/home/search/kemView.do?kemId=331697&ar=relateCourse Use Case 시스템 외부 관점, 특히 사용자/Actor 관점에서 해당 시스템의 기능과 동작방식을 나타낸 것 향후 테스트/검증 시에도 유용하게 활용됨 Use Case 표현 스타일 Use Case Diagram Use Case Description 작성 순서 1. Actor와 goal (actor 가 시스템에 요구하는 것) 식별 2. 관계정의 (A-A, A-U, U-U) 3. Normal flow 작성 4. Sub flow, Alternate/exception flow ..

* KOWC에 등록된 동국대학교 최은만 교수님의 강의내용을 공부목적으로 정리한 글임을 밝힙니다. | 출처 : http://www.kocw.net/home/search/kemView.do?kemId=331697&ar=relateCourse 분석방법론에 대한 관점 사용자의 요구를 분석하는 방법에는 구조적 분석과 객체지향 분석 방법이 있으며, 어떤 분석기법을 적용하느냐에 따라 디자인하는 관점이 상이해짐 C Program = .h (구조체 / 자료) +. c (함수) >> '함수, Process 에 초점' 객체지향언어(Java, C++, C#..) = 자료와 함수가 class로 묶여있음 >> 'class의 정의와속성, 관계에 초점' 구조적 분석 사용자 요구사항을 파악하기 위해 자료의 흐름과 절차를 그림중심으로..

* KOWC에 등록된 동국대학교 최은만 교수님의 강의내용을 공부목적으로 정리한 글임을 밝힙니다. | 출처 : http://www.kocw.net/home/search/kemView.do?kemId=331697&ar=relateCourse 요구분석 요구분석 시 사용자 요구사항을 잘 분석하는 것도 물론 중요하지만, 그 이전에 개발자가 기존시스템의 문제나 새로운 기능을 나름대로 분석해 보는 활동 역시 중요하며, 이러한 요구분석의 최종 산출물로 SRS(Software Requirement Specification Document, 요구분석서))가 만들어 짐 소프트웨어에서 요구 무엇을(What)을 구축할 것인가를 나타낸 것으로, 이러한 요구를 명확히 정립해두어야 정확한 이해와 전달(소통), 명세에 기반한 관리가 ..