소프트웨어 설계

Software design
시리즈의 일부
소프트웨어 개발
핵심 활동
패러다임 및 모델
방법론 및 프레임워크
지원 분야
프랙티스
도구들
지식의 표준과 본문
용어집
개요

소프트웨어 설계는 에이전트가 일련의 원시 구성 요소를 사용하여 [1]제한에 따라 목표를 달성하기 위한 소프트웨어 아티팩트의 사양을 생성하는 프로세스입니다.소프트웨어 설계에서는 "복잡한 시스템의 개념화, 프레이밍, 구현, 커미셔닝 및 최종 수정에 관련된 모든 활동" 또는 "요건 사양을 따르는 활동 및 프로그래밍 전 활동"을 다음과 같이 나타낼 수 있습니다.스타일화된 소프트웨어 엔지니어링 [2]프로세스입니다.

소프트웨어 설계에는 보통 문제 해결과 소프트웨어 솔루션 계획이 포함됩니다.여기에는 낮은 수준의 구성요소 및 알고리즘 설계와 높은 수준의 아키텍처 설계가 모두 포함됩니다.

개요

소프트웨어 설계는 하나 이상의 문제에 대한 소프트웨어 솔루션을 구상하고 정의하는 프로세스입니다.소프트웨어 설계의 주요 컴포넌트 중 하나는 소프트웨어 요건 분석(SRA)입니다.SRA는 소프트웨어 엔지니어링에 사용되는 규격을 나열하는 소프트웨어 개발 프로세스의 일부입니다.소프트웨어가 "반자동" 또는 사용자 중심의 경우 소프트웨어 설계에는 이러한 사양을 결정하는 데 도움이 되는 스토리보드를 생성하는 사용자 경험 설계가 포함될 수 있습니다.소프트웨어가 완전히 자동화되어 있는 경우(사용자 또는 사용자 인터페이스가 없음을 의미), 계획된 이벤트 시퀀스를 설명하는 흐름도 또는 텍스트처럼 소프트웨어 설계가 간단할 수 있습니다.Unified Modeling Language 및 Fundamental 모델링 개념과 같은 준표준 방식도 있습니다.어느 경우든 계획의 일부 문서는 일반적으로 설계의 산물이다.또한 설계에 사용되는 기술의 가용성에 따라 소프트웨어 설계는 플랫폼에 의존하지 않을 수도 있고 플랫폼에 따라 다를 수도 있습니다.

소프트웨어 분석과 설계의 주요 차이점은 소프트웨어 분석의 출력이 해결해야 할 작은 문제로 구성된다는 것입니다.또한 분석을 다른 팀원 또는 그룹에 걸쳐 매우 다르게 설계해서는 안 됩니다.이와는 대조적으로 설계는 능력에 중점을 두므로 동일한 문제에 대한 여러 설계가 존재할 수 있고 존재할 수 있습니다.신뢰성이 높은 프레임워크에서 작성되었는지, 적절한 설계 패턴으로 구현되었는지 여부에 따라 설계가 종종 환경에 따라 달라집니다.설계 예로는 운영 체제, 웹 페이지, 모바일 기기 또는 새로운 클라우드 컴퓨팅 패러다임 등이 있습니다.

소프트웨어 설계는 프로세스이자 모델입니다.설계 프로세스는 설계자가 구축할 소프트웨어의 모든 측면을 설명할 수 있는 일련의 단계입니다.창조적인 기술, 과거의 경험, 무엇이 "좋은" 소프트웨어를 만드는가에 대한 감각, 품질에 대한 전반적인 헌신은 유능한 설계의 중요한 성공 요인입니다.그러나 설계 프로세스가 항상 간단한 절차는 아니라는 점에 유의하십시오. 설계 모델을 건축가의 주택 설계도와 비교할 수 있습니다.건축할 물건의 전체(예를 들어, 집의 3차원 렌더링)를 나타내는 것으로 시작합니다.각 세부 사항(예를 들어 배관 부설)을 구성하기 위한 지침을 제공하기 위해 천천히 다듬어집니다.마찬가지로 소프트웨어용으로 생성된 설계 모델도 컴퓨터 소프트웨어의 다양한 보기를 제공합니다.기본 설계 원칙을 통해 소프트웨어 엔지니어는 설계 프로세스를 탐색할 수 있습니다.Davis는[3] 소프트웨어 설계에 대한 일련의 원칙을 제안합니다.이 원칙은 다음 목록에서 수정 및 확장되었습니다.

  • 설계 과정은 터널 비전에 시달려서는 안 된다.훌륭한 설계자는 문제의 요건, 즉 작업을 수행하는 데 사용할 수 있는 자원에 근거하여 각각을 판단하여 다른 접근방식을 고려해야 합니다.
  • 설계는 분석 모델까지 추적 가능해야 합니다.설계 모델의 단일 요소를 여러 요구 사항으로 추적할 수 있는 경우가 많기 때문에 설계 모델에 의해 요구사항이 어떻게 충족되었는지 추적할 수 있는 수단이 필요합니다.
  • 디자인은 바퀴를 재창조해서는 안 된다.시스템은 일련의 설계 패턴을 사용하여 구축되며, 이들 중 대부분은 이전에 경험한 적이 있습니다.이러한 패턴은 항상 재창조의 대안으로 선택되어야 한다.시간은 짧고 자원은 한정되어 있습니다.이미 존재하는 패턴을 통합함으로써 (해당하는 경우) 완전히 새로운 아이디어를 표현하는데 설계 시간을 투자해야 합니다.
  • 설계는 소프트웨어와 실제 존재하는 문제 사이의 지적 거리를 최소화해야 합니다.즉, 소프트웨어 설계의 구조는 가능한 한 문제 영역의 구조를 모방해야 합니다.
  • 설계는 통일성과 통합을 보여야 한다.디자인은 완전히 일관성이 있는 것처럼 보일 경우 균일합니다.이 결과를 얻기 위해서는 설계 작업을 시작하기 전에 설계 팀에 대해 스타일과 형식의 규칙을 정의해야 합니다.설계 구성요소 간의 인터페이스를 정의할 때 주의를 기울이면 설계가 통합됩니다.
  • 설계는 변화를 수용할 수 있도록 구성되어야 한다.다음 섹션에서 설명하는 설계 개념을 통해 설계가 이 원칙을 달성할 수 있습니다.
  • 설계는 비정상적인 데이터, 사건 또는 작동 조건이 발생한 경우에도 완만하게 열화되도록 구성되어야 한다.적절하게 설계된 소프트웨어는 결코 "폭탄"이 되어서는 안 됩니다.비정상적인 상황에 맞게 설계되어야 하며, 처리를 종료해야 할 경우에는 우아하게 해야 합니다.
  • 디자인은 코딩이 아닙니다. 코딩은 설계가 아닙니다.프로그램 컴포넌트에 대해 상세한 절차설계가 생성되어도 설계모델의 추상화 수준은 소스 코드보다 높다.코딩 수준에서 이루어지는 유일한 설계 결정은 절차 설계를 코딩할 수 있는 작은 구현 세부 사항을 다루어야 한다.
  • 설계 후가 아니라 설계 작성 시 품질을 평가해야 합니다.설계자가 개발 프로세스 전반에 걸쳐 품질을 평가하는 데 도움이 되는 다양한 설계 개념과 설계 척도를 사용할 수 있습니다.
  • 개념적(의미적) 오류를 최소화하기 위해 설계를 검토해야 합니다.나무를 위한 숲을 놓치고 디자인을 재검토할 때 세세한 부분까지 신경을 쓰는 경향이 있습니다.설계팀은 설계 모델의 구문에 대해 우려하기 전에 설계의 주요 개념 요소(누락, 모호성, 불일치)가 해결되었는지 확인해야 합니다.

디자인 컨셉

설계 개념은 소프트웨어 디자이너에게 보다 정교한 방법을 적용할 수 있는 기반을 제공합니다.일련의 기본적인 디자인 컨셉이 진화했습니다.그 예는 다음과 같습니다.

  1. 추상화 - 추상화란 개념이나 관측 가능한 현상의 정보 내용을 축소함으로써 일반적으로 특정 목적에 관련된 정보만을 유지하기 위해 일반화하는 과정 또는 결과입니다.배경 상세나 설명을 포함하지 않고 중요한 특징을 나타내는 행위입니다.
  2. 정교함 - 이것은 정교함의 과정입니다.계층은 프로그래밍 언어문에 도달할 때까지 거시적인 함수문을 단계적인 방식으로 분해함으로써 개발된다.각 단계에서, 소정의 프로그램의 하나 또는 복수의 명령이 보다 상세한 명령으로 분해된다.추상화와 정교화는 상호 보완적인 개념입니다.
  3. 모듈화 - 소프트웨어 아키텍처는 모듈이라고 불리는 컴포넌트로 나뉩니다.
  4. 소프트웨어 아키텍처 - 소프트웨어의 전체적인 구조와 그 구조가 시스템에 개념적인 무결성을 제공하는 방법을 나타냅니다.뛰어난 소프트웨어 아키텍처는, 퍼포먼스, 품질, 스케줄, 및 코스트의 각면에서, 프로젝트의 바람직한 결과에 대해서, 뛰어난 ROI를 가져옵니다.
  5. 제어 계층 - 프로그램 구성 요소의 구성을 나타내며 제어 계층을 암시하는 프로그램 구조입니다.
  6. 구조 파티션 - 프로그램 구조는 수평과 수직 양쪽으로 나눌 수 있습니다.수평 파티션은 각 주요 프로그램 기능에 대해 모듈러 계층의 개별 분기를 정의합니다.수직 파티셔닝은 제어와 작업을 프로그램 구조에서 하향식으로 분산해야 함을 나타냅니다.
  7. 데이터 구조 - 데이터의 개별 요소 간의 논리적 관계를 나타냅니다.
  8. 소프트웨어 절차 - 각 모듈을 개별적으로 처리하는 데 초점을 맞춥니다.
  9. 정보 숨김 - 모듈 내에 포함된 정보는 이러한 정보가 필요하지 않은 다른 모듈에서 액세스할 수 없도록 모듈을 지정하고 설계해야 합니다.

Grady Boch는 객체 모델에서 추상화, 캡슐화, 모듈화 및 계층을 기본적인 소프트웨어 설계 원칙으로 [4]언급하고 있습니다.PHAME(Principles of Hierarchy, Abstraction, Modularization, and Encapsulation)라는 약자가 이러한 4가지 기본 [5]원칙을 나타낼 때 사용되기도 합니다.

설계에 관한 고려 사항

소프트웨어 설계에는 많은 측면을 고려해야 합니다.각 고려사항의 중요성은 소프트웨어를 작성하기 위한 목표와 기대를 반영해야 합니다.그 중 몇 가지는 다음과 같습니다.

  • 호환성 - 소프트웨어는 다른 제품과의 상호 운용성을 위해 설계된 다른 제품과 함께 작동할 수 있습니다.예를 들어, 소프트웨어는 이전 버전의 소프트웨어와 하위 호환될 수 있습니다.
  • 확장성 - 기본 아키텍처를 크게 변경하지 않고 새로운 기능을 소프트웨어에 추가할 수 있습니다.
  • 모듈러성 - 그 결과 생성되는 소프트웨어는 잘 정의된 독립된 컴포넌트로 구성되어 유지보수가 용이해집니다.그런 다음 컴포넌트를 개별적으로 구현하고 테스트한 후 원하는 소프트웨어 시스템을 구성할 수 있습니다.이것에 의해, 소프트웨어 개발 프로젝트의 업무 분담이 가능하게 됩니다.
  • 폴트 톨러런스 - 소프트웨어는 컴포넌트 장애에 대한 내성을 갖추고 컴포넌트 장애로부터 회복할 수 있습니다.
  • 유지보수성 - 버그 수정 또는 기능 변경을 얼마나 쉽게 수행할 수 있는지를 나타내는 척도입니다.높은 유지보수성은 모듈화와 확장성의 산물일 수 있습니다.
  • 신뢰성(소프트웨어의 내구성) - 소프트웨어는 지정된 기간 동안 지정된 조건 하에서 필요한 기능을 수행할 수 있습니다.
  • 재사용 가능성 - 기존 소프트웨어의 일부 또는 모든 측면을 다른 프로젝트에서 거의 또는 전혀 수정하지 않고 사용할 수 있습니다.
  • 견고성 - 소프트웨어는 스트레스 하에서 작동하거나 예측 불가능한 입력 또는 비활성 입력을 허용할 수 있습니다.예를 들어 메모리 부족에 대한 복원력을 갖추고 설계할 수 있습니다.
  • 보안 - 소프트웨어는 적대적인 행위와 영향을 견디고 저항할 수 있습니다.
  • 조작성 - 소프트웨어 사용자 인터페이스를 대상 사용자/청취자에게 사용할 수 있어야 합니다.파라미터의 디폴트값은 대부분의 [6]사용자가 선택할 수 있도록 선택해야 합니다.
  • 퍼포먼스 - 소프트웨어는 사용자가 허용할 수 있는 시간 범위 내에 작업을 수행합니다.또한 메모리를 너무 많이 필요로 하지 않습니다.
  • 휴대성 - 소프트웨어는 다양한 조건과 환경에서 사용할 수 있어야 합니다.
  • 확장성 - 소프트웨어는 데이터 증가, 기능 추가 또는 사용자 수에 잘 적응합니다.

모델링 언어

모델링 언어는 일관된 규칙 집합에 의해 정의된 구조에서 정보, 지식 또는 시스템을 표현하기 위해 사용할 수 있는 모든 인공 언어입니다.이러한 규칙은 구조 내 구성 요소를 해석하는 데 사용됩니다.모델링 언어는 그래픽 또는 텍스트 형식일 수 있습니다.소프트웨어 설계용 그래픽 모델링 언어의 예는 다음과 같습니다.

  • ADL(Architecture Description Language)은 소프트웨어 시스템의 소프트웨어 아키텍처를 기술하고 나타내기 위해 사용되는 언어입니다.
  • 비즈니스 프로세스 모델링 표기법(BPMN)은 프로세스 모델링 언어의 한 예입니다.
  • EXPRESS 및 EXPRESS-G(ISO 10303-11)는 국제 표준 범용 데이터 모델링 언어입니다.
  • EEML(Extended Enterprise Modeling Language)은 여러 계층에 걸친 비즈니스 프로세스 모델링에 일반적으로 사용됩니다.
  • 흐름도는 알고리즘 또는 기타 단계별 프로세스를 개략적으로 표현한 것입니다.
  • FMC(Fundamental Modeling Concepts)는 소프트웨어 집약적인 시스템을 위한 모델링 언어입니다.
  • IDEF는 모델링 언어 패밀리로 기능 모델링용 IDEF0, 정보 모델링용 IDEF1X, 온톨로지 모델링용 IDEF5 등이 있습니다.
  • Jackson Structured Programming(JSP)은 데이터 스트림 구조와 프로그램 구조 간의 대응에 기초한 구조화된 프로그래밍 방법입니다.
  • LePUS3는 객체 지향 비주얼 디자인 기술 언어이며 주로 대규모 객체 지향(Java, C++, C#) 프로그램 및 디자인 패턴 모델링에 적합한 정식 사양 언어입니다.
  • Unified Modeling Language(UML; 통합 모델링 언어)는 소프트웨어를 구조적으로나 동작적으로 기술하는 일반적인 모델링 언어입니다.그래픽 표기가 있어 프로파일(UML)을 사용하여 확장할 수 있습니다.
  • 합금(사양 언어)은 소프트웨어 시스템에서 복잡한 구조적 제약 및 동작을 표현하기 위한 범용 사양 언어입니다.1차 관계 논리에 기초한 간결한 언어 기반을 제공합니다.
  • 시스템 모델링 언어(SysML)는 시스템 엔지니어링을 위한 새로운 범용 모델링 언어입니다.
  • 서비스 지향 모델링 프레임워크(SOMF)[7]

설계 패턴

소프트웨어 설계자 또는 설계자는 과거에 다른 사람이 방문하거나 해결한 설계 문제를 식별할 수 있습니다.일반적인 문제에 대한 해결책을 설명하는 템플릿 또는 패턴을 설계 패턴이라고 합니다.이러한 패턴을 재사용하면 소프트웨어 개발 프로세스를 [8]가속화할 수 있습니다.

기술.

소프트웨어와 관련하여 "설계"라는 용어를 사용하는 것의 어려움은 어떤 의미에서는 프로그램의 소스 코드가 그 프로그램이 생산하는 프로그램의 설계라는 것이다.이것이 사실이라면, "소프트웨어 설계"는 설계의 설계를 말합니다.Edsger W. Dijkstra는 이러한 시맨틱 수준의 [9]계층화를 컴퓨터 프로그래밍의 "급격한 신규성"이라고 언급했으며, Donald Knuth는 TeX를 쓴 자신의 경험을 사용하여 프로그램을 구현하기 전에 설계하려고 시도해도 소용없음을 설명했습니다.

TX를E 지정하기만 하고 초기 구현에 완전히 참여하지 않았다면 TX는 완전히 실패했을 것입니다.구현 프로세스에서는 항상 예상치 못한 질문과 원래의 사양을 [10]개선할 수 있는 방법에 대한 새로운 통찰력을 얻을 수 있었습니다.

사용.

소프트웨어 설계 문서는 컴퓨터 프로그래밍 전에 제약사항, 사양 및 요건을 조정할 수 있도록 검토 또는 제시할 수 있습니다.재설계는 프로그래밍된 시뮬레이션 또는 프로토타입을 검토한 후에 이루어질 수 있습니다.계획이나 요구사항 [11]분석 없이 프로그래밍 과정에서 소프트웨어를 설계할 수 있지만, 더 복잡한 프로젝트에서는 이것이 실현 가능하다고 간주되지 않습니다.프로그래밍 전에 별도의 설계를 통해 다원적 설계자 및 주제 전문가(SME)가 유용하고 기술적으로 견고한 소프트웨어를 위해 고도로 숙련된 프로그래머와 협업할 수 있습니다.

「 」를 참조해 주세요.

Wikimedia Commons에는 소프트웨어 설계와 관련된 미디어가 있습니다.

레퍼런스

  1. ^ 랄프, P.와 완드, Y. (2009).설계 개념의 정식 정의를 위한 제안.Lytinen, K., Loucopoulos, P., Mylopoulos, J. 및 Robinson, W. 편집자, 설계 요구사항 워크숍(LNBIP 14), 페이지 103-136.Springer-Verlag, 페이지 109 doi:10.1007/978-3-540-92966-6_6.
  2. ^ Freeman, Peter; David Hart (2004). "A Science of design for software-intensive systems". Communications of the ACM. 47 (8): 19–21 [20]. doi:10.1145/1012037.1012054. S2CID 14331332.
  3. ^ Davis, A: "201 소프트웨어 개발 원칙", McGraw Hill, 1995.
  4. ^ Booch, Grady; et al. (2004). Object-Oriented Analysis and Design with Applications (3rd ed.). MA, USA: Addison Wesley. ISBN 0-201-89551-X. Retrieved 30 January 2015.
  5. ^ Suryanarayana, Girish (November 2014). Refactoring for Software Design Smells. Morgan Kaufmann. p. 258. ISBN 978-0128013977.
  6. ^ Carroll, John, ed. (1995). Scenario-Based Design: Envisioning Work and Technology in System Development. New York: John Wiley & Sons. ISBN 0471076597.
  7. ^ Bell, Michael (2008). "Introduction to Service-Oriented Modeling". Service-Oriented Modeling: Service Analysis, Design, and Architecture. Wiley & Sons. ISBN 978-0-470-14111-3.
  8. ^ Judith Bishop. "C# 3.0 Design Patterns: Use the Power of C# 3.0 to Solve Real-World Problems". C# Books from O'Reilly Media. Retrieved 2012-05-15. If you want to speed up the development of your .NET applications, you're ready for C# design patterns -- elegant, accepted and proven ways to tackle common programming problems.
  9. ^ Dijkstra, E. W. (1988). "On the cruelty of really teaching computing science". Retrieved 2014-01-10.
  10. ^ Knuth, Donald E. (1989). "Notes on the Errors of TeX" (PDF).
  11. ^ Ralph, P. 및 Wand, Y. 디자인 컨셉의 정식 정의를 위한 제안.Lytinen, K., Loucopoulos, P., Mylopoulos, J. 및 Robinson, (에드), 디자인 요건 엔지니어링: 10년 전망: Springer-Verlag, 2009 페이지 103-136.

^Roger S. Pressman (2001). Software engineering: a practitioner's approach. McGraw-Hill. ISBN 0-07-365578-3.