소프트웨어 설계(애플리케이션 설계)

1. 공통 모듈 설계 (1) 공통 모듈

(1)모듈 : 독립된 하나의 소프트웨어 또는 하드웨어 단위를 지칭하는 용어 (응집도는 높게, 결합도는 낮게) (2)공통 모듈 원칙 (정명완 일추) ①정확성Correctness ②명확성Claruty ③완전성Completeness ④일관성Consistency ⑤추적성Traceability (3)모듈화 기법 ①루틴 ②메인루틴: 메인함수 ③서브루틴: 사용자 만든 함수 호출 (4)바람직한 모듈 설계 방안 1. 모듈의 독립성과 재사용성을 높이기 위해 결합도는 낮추고, 응집도는 높인다. (결합도는 Coupling이라고도 한다.) 2. 모듈의 복잡도와 중복성은 줄이고, 일관성은 유지 한다. 3. 모듈의 기능은 예측이 가능 해야 하며, 지나치게 제안적이어서는 안된다. 4. 적당한 모듈 크기를 유지한다. 5. 모듈 간의 효과적인 제어를 위해 설계에서 계층적 자료 조직이 제시되어야 한다. 6. 유지보수가 용이해야 하고, 이식성을 고려해야 한다. (5)팬인과 팬아웃 분석을 통하여 시스템의 복잡도를 측정할 수 있다. ①FAN-IN: 어떤 모듈을 제어하는 모듈의 수(상위 모듈의 수) / ②FAN-OUT: 어떤 모듈에 의해 제어 되는 모듈의 수 (하위 모듈의 수) ð  시스템 복잡도를 최적화하기 위해서는 팬인은 높게 팬아웃은 낮게 설계해야 한다.

1. 공통 모듈 설계 (2) 설계 모델링

(1)소프트웨어 설계 유형 (자아인프협) ①자료구조 설계 : 소프트웨어를 구현하는데 필요한 자료 구조로 변환하는 과정 ②아키텍처 설계(설계도) : 소프트웨어를 구성하는 컴포넌트 간의 관계(=아키텍처) 를 정의 상위 설계     ③인터페이스 설계 : 소프트웨어와 상호작용(=인터페이스)하는 컴퓨터 시스템, 사용자 등이 어떻게 통신 하는지를 기술 ④프로시저 설계 : 소프트웨어 컴포넌트의 프로시저 서술로 변환하는 과정 ⑤협약에 의한 설계: 클래스에 대한 여러 가정을 공유하도록 명세한 설계                     1. 선행조건 : 컴포넌트의 오퍼레이션 사용 전에 참이 되어야 할 조건 (전)                     2. 결과조건 : 사용 후 만족되어야 할 조건 (후) 3. 불변조건 : 오퍼레이션이 실행되는 동안 항상 만족되어야 할 조건 (항상)   하위 설계 : 모듈 설계 (2)소프트웨어 설계 원리 ①상향식 설계 : 하위 기능들로부터 시작하여 à 제일 상위에 있는 기능 접근해 가는 방식 ②하향식 설계 : 상위 기능에서 시작하여 à 하위 기능들로 분할해 가면서 설계하는 방식 (3)코드 설계 종류 ①연상코드: KR 코리아, US미국 ②블록코드: 전화번호 국번 02는 서울, 031은 경기도, 블록으로 구분  ③순차코드: 순서대로 일련번호 부여 ④표의 숫자 코드: 물리적인 수치인 길이, 넓이, 용량 등을 표시한 코드 ⑤십진코드: 10진수 형태 코드 ⑥그룹 분류식 코드: 학번 입학연도 (4)코드 오류 종류 ①사본 오류; Transcription Error : 한 자리 잘못 표기 ②전위 오류; Transposition Error : 연속된 두 글자가 서로 바뀌어 표기 ③생략 오류; Omission Error : 한 글자를 빼 먹고 기술한 경우 ④첨가 오류; Addition Error : 한 글자를 추가되어 기술한 경우 ⑤이중전위 오류; Double Transposition Error : 전위 오류가 중복 발생한 경우   (5)HIPO; Hierarchy Input Process Output 계층적 입력 처리 출력 : 시스템의 분석 및 설계, 문서화 할 때 사용되며 하향식 소프트웨어 개발을 위한 문서화 도구 이다. ①체계적인 문서관리가 가능하다. ②기호, 도표 등을 사용해서 보기가 쉽고 이해가 쉽다 ③기능과 자료의 의존 관계를 동시에 표현할 수 있다. ④변경, 유지보수가 용이하다. ⑤시스템의 기능을 고유 모듈(하향식)로 분할하여 이들 간의 인터페이스를 계층구조로 표현한 것을 HIPO 차트라고 한다. ⑥HIPO차트의 종류 ①가시적 도표 ②총체적 도표 ③세부적 도표

반응형

1. 공통 모듈 설계 (3) 소프트웨어 아키텍처

(1)소프트웨어 아키텍처 : 구성요소 간의 관계를 표현하는 시스템의 구조(설계도) (2)소프트웨어 아키텍처 4+1 : 고객의 요구사항을 정리해 놓은 시나리오를 4개의 관점에서 바라보는 소프트웨어적인 접근방법. (유논프구배) ①유스케이스 뷰 ②논리 뷰 ③프로세스 뷰 ④구현 뷰 ⑤배포 뷰 (2)소프트웨어 아키텍처 비용 평가 모델 종류 (SACCA ) ①SAAM; Software Architecture Analysis Method : 경험이 없는 조직에서도 활용 가능한 비용 평가 모델 ②ATAM; Architecture Trade-off Analysis Method : 아키텍처 품질 속성을 만족시키는지 판단 및 품질 속성들의 이행 상충관계까지 평가 ③CBAM; Cost Benefit Analysis Method : 경제적 의사결정에 대한 요구를 충족하는 비용 평가 모델 ④ADR; Active Design Review : 소프트웨어 아키텍처 구성요소 간 응집도를 평가하는 모델 ⑤ARID; Active Reviews for Intermediate Designs : 전체 아키텍처가 아닌 특정 부분에 대한 품질요소에 집중하는 비용 평가 모델 (3)소프트웨어 아키텍처 패턴 유형 ①계층화 패턴 : OSI7계층 ②클라이언트-서버 패턴 ③파이프-필터 패턴 ④브로커 패턴 ⑤모델-뷰 패턴; MVC; Model View Controller pattern (4)소프트웨어 아키텍처 시스템 품질속성 (가변성보사시) ①가용성Availability ②변경 용이성Modifiability ③성능Performance ④보안성Security ⑤사용 편의성Usability ⑥시험 용이성Testability

2. 객체지향 설계 (1) 객체지향

(1)객체지향 개념 : 실세계의 개체를 속성(Attribute)과 메서드(Method)가 결합한 형태의 객체(Object)로 표현하는 기법이다. (2)객체 지향 구송요소 (클객메 메인속) ①클래스Class ②객체Object ③메소드Method ④메시지 Message ⑤인스턴스 Instance ⑥속성 Property (3)객체지향기법 (캡상다추정관) ①갭슐화; Encapsulation : 관련성이 많은 데이터랑 함수들 이런 걸 묶어서 처리하는 것을 캡슐화 ②상속성Inheritance : 부모 클래스에서 자식 클래스로 상속 받는 것. ③다형성Polymorphism : 하나의 메시지에 대해서 여러 가지 방법으로 대답할 수 잇는 능력 ④추상화 Abstraction : 공통 성질들이 있는데 이것을 추출해서 하나의 클래스로 만드는 것을 추상화(네오, 모피어스를 추상화하면 사람이 된다.) ⑤정보은닉Information Hiding : 데이터나 필요하기 않은 것, 외부에 공개되지 않아야 될 메서드 같은 경우들을 안으로 숨기는 것 ⑥관계성Relationship (집분연일특) 1.     집단화 : is part of, part-whole, 2.     분류화 : is-instance-of, 관계성      3.  연관화 : is-member-of 4.     일반화 : is-a, 상위 클래스의 특성을 하위 클래스가 상속받음 5.     특수화 : is-a, 상위 클래스의 특성을 상속받으면서 하위 클래스에서 나름대로 수정을 가하고 자기 자신의 고유한 특성을 갖는 관계 (4)객체지향설계원칙 (SOLID) ①단일 책임의 원칙; Single Responsibility Principle : 사장이란 클래스가 있는데 사장 일만 해야 하는데 사원 일도 하고 있다. ②개발 폐쇄 원칙; Open Close Principle : 확장에는 열려 있고 변경에는 닫혀 있어야 한다. ③리스코프 치환의 원칙; Liskov Substitution Principle : 자식은 부모 클래스를 대체할 수 있어야 된다는 것이다. ④인터페이스 분리의 원칙; Interface Segregation Principle : 자기가 안 쓰는 건 만들지 말자는 원칙이다. ⑤의존성 역전의 원칙; Dependency Inversion Principle : 추상을 매개로 메시지를 주고 받아서 관계를 최소화해야 된다는 겁니다. (4)객체지향분석OOA; Object Oriented Analysis의 개념 : 사용자의 요구사항을 분석하여 요구된 문제와 관련된 클래스, 속성과 연산, 관계 등으로 나누어서 분석하는 기법 (5)객체 지향 방법론 종류 ① OOSE; Object Oriented Software Engineering (야콥슨Jacobson) :유스케이스에 의한 접근 방법으로 유스케이스를 모든 모델의 근간으로 활용 ② OMT; Object Modeling Technology (럼바우 Rumbaugh) : 객동기 1.     객체 모델링Object Modeling : 객체 다이어그램 2.     동적 모델링Dynamic Modeling : 상태 다이어그램 3.     기능 모델링Functional Modeling : 자료 흐름도 DFD ③ OOD; Object Oriented Design (부치 BooCh) ④ Coad와 Yourdon방법론은 E-R다이어그램을 사용한다. (Entity-Relationship Diagram엔티티 관계 도형) ⑤ Wirfs-Brock 방법론은 분석과 설계 간의 구분이 없고 고객 명세서를 평가해서 설계 작업까지 연속적으로 수행하는 분석 방법이다.

2. 객체지향 설계 (2) 디자인 패턴

(1)디자인 패턴의 개념 : 소프트웨어 설계에서 공통으로 발생하는 문제에 대해 자주 쓰이는 설계 방법을 정리한 패턴 (2)디자인 패턴 구성요소 (패문솔사결샘) ①패턴의 이름 ②문제 및 배경 ③솔루션 ④사례 ⑤결과 ⑥샘플코드 (3)디자인 패턴 유형 (Gangs of four) GoF 목적 : 생구행 ①생성 ②구조 ③행위 (4)디자인패턴종류 ① (생:빌 프로 팩앱싱)     생성 패턴 : 빌더;Builder, 프로토타입;Prototype, 팩토리;Factory, 앱스트랙;Abstract, 싱글톤Singleton) ② (구:브데퍼플 프록 컴어) 구조 패턴 : 브릿지Bridge 데코레이터Decorator 퍼사이드Facade 플라이웨이트Flyweight 프록시Proxy 컴포지트Composite 어댑터Adapter ③ 행위 패턴 : 생성패턴과 구조패턴 제외하고 나머지는 모두 행위 패턴이다.. (5)디자인 패턴의 장단점 장점 1. 재사용을 통한 개발 시간 단축 2. 소프트웨어 구조 파악 용이 3. 객체 지향 설계 및 구현의 생산성을 높이는 데 적합 4. 소스코드 최소화 단점 1. 객체 지향 설계 / 구현 위주로 사용 2. 초기 투자 비용의 부담