Coding-Yuns

소프트웨어 설계 - 3

필수암기 363선

21. 자료 사전의 표기 기호

22. SADT

● SoftTech 사에서 개발한 구조적 분석 및 설계 도구이다.

● 블록 다이어그램을 채택한 자동화 도구이다.

23.UML

● 시스템 분석, 설계, 구현 등 시스템 개발 과정에서 시스템 개발자와 고객 또는 개발자 상호 간의 의사소통이 원활하게 이루어지도록 표준화한 대표적인 객체지향 모델링 언어이다.

● 구성요소 : 사물(Things), 관계(Relationships), 다이어그램(Diagram)

24.HIPO

● 시스템의 분석 및 설계나 문서화할 때 사용되는 기법으로, 시스템 실행 과정인 입력, 처리, 출력의 기능을 나타낸다.

● 하향식 소프트웨어 개발을 위한 문서화 도구이다.

● 기호, 도표 등을 사용하므로 보기 쉽고 이해하기도 쉽다. 

● 기능과 자료의 의존 관계를 동시에 표현할 수 있다.

● 시스템의 기능을 여러 개의 고유 모듈들로 분할하여 이들 간의 인터페이스를 계층 구조로 표현한 것을 HIPO Chart라고 한다.

● HIPO Chart의 종류 : 가시적 도표(Visual Table of Contents), 총제적 도표(Overview Diagram), 세부적 도표(Detail Diagram)

25. 의존(Dependency) 관계

● 연관 관계와 같이 사물 사이에 서로 연관은 있으나 필요에 의해 서로에게 영향을 주는 짧은 시간 동안만 연관을 유지하는 관계를 표현한다.

● 일반적으로 한 클래스가 다른 클래스를 오퍼레이션의 매개 변수로 사용하는 경우에 나타나는 관계이다.

26. 실체화(Realization) 관계

● 사물이 할 수 있거나 해야 하는 기능(오퍼레이션, 인터페이스)으로 서로를 그룹화할 수 있는 관계를 표현한다.

● 한 사물이 다른 사물에게 오퍼레이션을 수행하도록 지정하는 의미적 관계이다.

27. 일반화(Generalization) 관계

● 하나의 사물이 다른 사물에 비해 더 일반적인지 구체적인지를 표현하다.

● 예를 들어 차는 버스, 트럭, 택시보다 일반적인 개념이고 반대로 버스, 트럭, 택시는 차보다 구체적인 개념이다.

28. 스테레오 타입(Stereotype)

● UML에서 표현하는 기본 기능 외에 추가적인 기능을 표현하기 위해 사용한다.

● 길러멧(Guilemet)이라고 부르는 겹화살괄호(<<>>) 사이에 표현할 형태를 기술한다.

29. 구조적(정적) 다이어그램

● 클래스 다이어그램 : 클래스와 클래스가 가지는 속성, 클래스 사이의 관계를 표현하며, 시스템의 구조를 파악하고 구조상의 문제점을 도출할 수 있음

● 객체(Object) 다이어그램 : 클래스에 속한 사물(객체)들, 즉 인스턴스를 특정 시점의 객체와 객체 사이의 관계로 표현하며, 럼바우 객체지향 분석 기법에서 객체 모델링에 활용됨

● 컴포넌트 다이어그램 : 실제 구현 모듈인 컴포넌트 간의 관계나 컴포넌트 간의 인터페이스를 표현하며, 구현 단계에서 사용됨

● 배치(Deployment) 다이어그램 : 결과물, 프로세스, 컴포넌트 등 물리적 요소들의 위치를 표현하며, 구현 단계에서 사용됨

● 복합체 구조(Composite Structure) 다이어그램 : 클래스나 컴포넌트가 복합 구조를 갖는 경우 그 내부 구조를 표현함

● 패키지 다이어그램 : 유스케이스나 클래스 등의 모델 요소들을 그룹화한 패키지들의 관계를 표현함

30. 사용자 인터페이스(UI)의 특징

● 사용자의 편리성과 가독성을 높임으로써 작업 시간을 단축시키고 업무에 대한 이해도를 높여준다.

● 사용자 중심으로 설계되어 사용자 중심의 상호 작용이 되도록 한다.

● 수행 결과의 오류를 줄인다.

● 사용자의 막연한 작업 기능에 대해 구체적인 방법을 제시해 준다.

소프트웨어 설계 - 2

필수암기 363선

11. 현행 시스템 파악 절차 

●  1단계 : 시스템 구성, 시스템 기능, 시스템 인터페이스 파악

●  2단계 : 아키텍처 구성, 소프트웨어(DBMS, 운영체제 등) 구성 파악

●  3단계 : 하드웨어 구성, 네트워크 구성 파악

12. DBMS 분석 시 고려사항

● 가용성

● 성능

● 기술 지원

● 상호 호환성

● 구축 비용

13. WAS(Web Application Server)

● 정적인 콘텐츠 처리를 하는 웹 서버와 달리 사용자의 요구에 따라 변하는 동적인 콘텐츠를 처리하기 위해 사용되는 미들웨어이다.

● 종류 : Tomcat, GlassFish, JBoss, Jetty, Jeus, Resin, WebLogic, WebSphere 등

14. 비기능 요구사항

●  성능 요구사항 : 처리 속도 및 시간, 처리량 등의 요구사항

●  보안 요구사항 : 시스템의 데이터 및 기능, 운영 접근을 통제하기 위한 요구사항

●  품질 요구사항 : 품질 평가 대상에 대한 요구사항

15. 요구사항 개발 프로세스

도출(Eliciation) → 분석(Analysis) → 명세(Specification) → 확인(Validation)

16. 요구사항 분석

● 소프트웨어 개발의 실제적인 첫 단계로 개발 대상에 대한 사용자의 요구사항을 이해하고 문서화(명세화)하는 활동을 의미한다.

● 사용자의 요구를 정확하게 추출하여 목표를 정하고, 어떤 방식으로 해결할 것인지를 결정한다.

● 개발 대상에 대한 사용자의 요구사항 중 명확하지 않거나 모호하여 이해되지 않는 부분을 발견하고 이를 걸러 내기 위한 과정이다.

● 사용자의 요구사항은 예외가 많고 지속적으로 변하므로 열거와 구조화가 어렵다.

● 내용이 중복되거나 하나로 통합되어야 하는 등 서로 상충되는 요구사항이 있으며 이를 중재하는 과정이다.

● 요구사항 분석을 위해 UML(Unified Modeling Language), 자료 흐름도(DFD), 자료 사전(DD), 상태 전이도(STD), 제어 명세서 등의 도구를 이용한다.

17. 기능 요구사항

● 시스템이 무엇을 하는지, 어떤 기능을 하는지에 대한 사항

● 시스템의 입력이나 출력으로 무엇이 포함되어야 하는지, 시스템이 어떤 데이터를 저장하거나 연산을 수행해야 하는지에 대한 사항

● 시스템이 반드시 수행해야 하는 기능

● 사용자가 시스템을 통해 제공받기를 원하는 기능

18. 요구사항 명세 기법

19. 요구사항 확인(요구사항 검증)

● 분석가가 요구사항을 정확하게 이해한 후 요구사항 명세서를 작성했는지 확인(Validation)하는 것이 필요하다.

● 요구사항이 실제 요구를 반영하는지, 서로 상충되는 요구사항은 없는지 등을 점검한다.

● 개발이 완료된 후 문제가 발견되면 재작업 비용이 발생할 수 있으므로 요구사항 검증은 매우 중요하다.

● 요구사항 검증 과정을 통해 모든 문제를 확인할 수 있는 것은 아니다.

20. 자료 흐름도의 구성 요소

소프트웨어 설계 - 1

필수 암기 363선

1. 소프트웨어 공학

● 소프트웨어의 위기를 극복하기 위한 방안으로 연구된 학문이다.
● 소프트웨어의 개발, 운용, 유지보수에 대한 체계적인 접근 방법이다.

● 소프트웨어의 품질과 생산성을 향상할 목적으로 한다.

● 경제적인 비용을 들여 신뢰성 높은 소프트웨어를 개발하기 위해 공학적 원리를 정립하고 이를 적용하는 것이다.

2. 소프트웨어 공학의 기본 원칙

● 현대적인 프로그래밍 기술을 계속적으로 적용해야 한다.

● 개발된 소프트웨어의 품질이 유지되도록 지속적으로 검증해야 한다.

● 소프트웨어 개발 관련 사항 및 결과에 대한 명확한 기록을 유지해야 한다.

3. 폭포수 모형(Waterfall Model)

● 이전 단계로 돌아갈 수 없다는 전제하에 각 단계를 확실히 매듭짓고 그 결과를 철저하게 검토하여 승인 과정을 거친 후에 다음 단계를 진행하는 개발 방법론이다.

● 보헴(Bohem)이 제시한 고전적 생명 주기 모형이다.

● 가장 오래되고 가장 폭넓게 사용된 전통적인 소프트웨어 생명 주기 모형이다.

● 개발 과정에서 발생하는 요구사항을 반영하기 어렵다.

4. 나선형 모형(Spiral Model, 점진적 모형)

● 보헴(Bohem)이 제안한 것으로, 폭포수 모형과 프로토타입 모형의 장점에 위험 분석 기능을 추가한 모형이다.

● 나선을 따라 돌듯이 여러 번의 소프트웨어 개발 과정을 거쳐 점진적으로 완벽한 최종 소프트웨어를 개발하는 것이다.

● 계획 수립 > 위험 분석 > 개발 및 검증 > 고객 평가 과정이 반복적으로 수행된다.

5. 애자일 모형(Agaile Model)

● 고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하면서 개발 과정을 진행한다.

● 애자일 모형을 기반으로 하는 소프트웨어 개발 모형

- 스크럼(Scrum)

- XP(eXtreme Programming)

- 칸반(Kanban)

- 린(Lean)

- 크리스털(Crystal)

-  ASD(Adaptive Software Development)

- 기능 중심 개발(FDD: Feature Driven Development)

- DSDM(Dynamic System Development Method)

- DAD(Disciplined Agile Delivery)

6. 애자일 개발 4가지 핵심 가치

● 프로세스와 도구보다는 개인과 상호작용에 더 가치를 둔다.

● 방대한 문서보다는 실행되는 SW에 더 가치를 둔다.

● 계약 협상보다는 고객과 협업에 더 가치를 둔다.

● 계획을 따르기보다는 변화에 반응하는 것에 더 가치를 둔다.

7. 스크럼(Scrum) 기법의 주요 용어

● 스크럼 마스터(Scrum Master) : 스크럼 프로세스를 따르고, 팀이 스크럼을 효과적으로 활용할 수 있도록 보장하는 역할을 함.

● 제품 백로그(Product Backlog) : 스크럼 팀이 해결해야 하는 목록으로 소프트웨어 요구사항, 아키텍처 정의 등이 포함됨.

● 스프린트(Sprint) : 하나의 완성된 최종 결과물을 만들기 위한 주기로 보통 2~4주 정도의 기간 내에서 진행함.

● 속도(Velocity) : 한 번의 스프린트에서 한 팀이 어느 정도의 제품 백로그를 감당할 수 있는지에 대한 추정치

8. XP(eXtreme Programming)

● 수시로 발생하는 고객의 요구사항에 유연하게 대응하기 위해 고객의 참여와 개발 과정의 반복을 극대화하여 개발 생산성을 향상하는 방법이다.

● 대표적인 애자일 개발 방법론 중 하나이다.

● 짧고 반복적인 개발 주기, 단순한 설계, 고객의 적극적인 참여를 통해 소프트웨어를 빠르게 개발하는 것을 목적으로 함.

● 자동화된 테스팅 도구를 사용하여 테스트를 지속적으로 수행한다.

9. XP의 핵심가치

● 의사소통(Communication)

● 단순성(Simplicity)

● 용기(Courage)

● 존중(Respect)

●  피드백(Feedback)

10. XP의 주요 실천 방법

● Pair Programming(짝 프로그래밍) : 다른 사람과 프로그래밍을 수행함으로써 개발에 대한 책임을 공동으로 나눠 갖는 환경을 조성함.

● Collective Ownership(공동 코드 소유) : 개발 코드에 대한 권한과 책임을 공동으로 소유함

● Continuous Integration(계속적인 통합) : 모듈 단위로 나눠서 개발된 코드들은 하나의 작업이 마무리될 때마다 지속적으로 통합됨.

● Refactoring(리팩토링) : 프로그램 기능의 변경 없이, 단순화, 유연성 강화 등을 통해 시스템의 내부 구조를 재구성함.