소프트웨어 공학

임정택·2021년 4월 4일
0

소프트웨어공학

목록 보기
1/1

시작

소프트웨어는 단순히 코드의 나열이 아니라 작은 기능들 혹은 모듈들로 구성되어 있는 하나의 구조이다.
어떻게 하면 복잡하고 큰 시스템을 개별적으로 유지보수하여 진화하도록 부분들을 나눌수 있는가?이 이론의 시발점이다.

  • 용어 정의
    Architecture: 기능적 혹은 비기능적요구를 어떻게 분할할 것인지에 대한 의사결정의 집합
    Design: 기능적 요구에 대한 구현에 초점

Architecutre Design

  1. 어떻게 하면 복잡하고 큰 시스템을 작은 시스템으로 분할 할 것인가

    • 최대한 독립적으로 시스템을 분할하기

      • 독립적으로 쪼갠 문제들과 유사한 기존에 solution이 있는 문제들을 참고하여 어떻게 하면 문제들을 잘 해결하여 합칠 수 있을지 생각
      • 개별부분들이 독자적으로 개발 진화될수 있도록 → 관심사의 분리 ,내 모듈에 대한 변경이 다른 섭시스템에 변경의 영향을 최소화 시켜야함
    • But,어려운 경우도 있음!, 모든 시스템에 걸쳐 영향이 가는 problem( _Cross cutting Problem)

      • Load Balancer

        로드밸런서는 서버에 가해지는 부하(=로드)를 분산(=밸런싱)해주는 장치 또는 기술을 통칭합니다. 클라이언트와 서버풀(Server Pool, 분산 네트워크를 구성하는 서버들의 그룹) 사이에 위치하며, 한 대의 서버로 부하가 집중되지 않도록 트래픽을 관리해 각각의 서버가 최적의 퍼포먼스를 보일 수 있도록 합니다.

      • Caching, log, nonFunctional Problem

  2. 소프트웨어와 하드웨어를 매핑시킬것인가

  3. 어떤 OS 혹은 플랫폼을 이용하여 개발할 것인가

  4. 어떻게하면 분할된 여러 모듈 혹은 서브시스템들을 하나로 합칠 것인가 (Architecture style)

Well Known Architectural Styles

  • Components
  • Connectors
  • Interfaces
  1. Pipe-Filter Style(Unix)

    재사용성,범용성이 매우 높은 프로그램들(Filter)로 쪼개서 이를 연결 혹은 합쳐 기능을 구현하도록 함.

    → 우리문제를 해결하는데 사용하는 Filter가 다른문제를 해결하는데 재사용될 수 있도록 함

    (단일 입력 → 단일 출력)

    조합은 어떻게 ? → Pipe

    ex : ls folder-name | grep -v match-string | more

    앞명령어의 표준출력을 다음 필터의 표준입력으로 연결하라(|를 통해)

  2. MVC Architecture

    Model(전체시스템의 데이터처리부분), View(사용자가 볼 수 있는 부분) ,Controller(사용자가 요청하는 부분) 이때, 한 모델에대하여 여러가지 View가 있을 수 있음

  3. Rest Architecutre (Represented Stated Transfer(not Procedure call))

    • 리소스(정보자원) 기반 아키텍쳐로 API 를 설계하기 위한 기술

    • 클라이언트와 서버가 독자적으로 진화 발전시킬수 있도록 하는 장점,

    • 서버에게 명령을 통해 어떤 기능을 수행하는게 아니라 Resource를 요청으로 하여 기능을 처리하도록 하는거임

    • Properties

      무상태성: 현재 리소스 요청에 대해서만 처리 , 이전에 무슨 명령을 써서 어떤 리소스에 대한요청이 왔는지 history를 서버에게 부담을 주지 않음 → 쿠키를 통해 이전 history를 알 수 있음

  • Uniform Interface

    웹브라우저에서 리소스(리소스가 실재하진 않지만 있는거처럼)에대한 주소를 명령으로 쳐서 보냄(URI). 그런데 이런 주소가 사이트마다 다르고 요청 자원마다 다르게 되면 안되니 이걸 통합(Uniform)시켜놓은 API가 있음 → URI (Uniformed Resouce Idendified)
    URI에 대해 더 자세한 정보를 알고 싶다면 다음을 참고하라

        [더 나은 웹](https://www.betterweb.or.kr/blog/url%EC%9D%B4%EB%9E%80/)
        

요구분석

소프트웨어 엔지니어의 역할

  • 고객을 이해해서 고객과 개발자의 bridge의 역할을 해주는게 엔지니어의 역할
  • Requriments Enigneering을 할 수 있는 능력
  • 주어진문제를 고객관점에서 잘 이해하고 정확한 명세를 작성해야함
  • 지금까지의 단계를 잘 거쳐여함(요구분석, UseCases, Domain Modeling)

UserCase와 Domain Modeling의 차이점

  • UserCase
    모든 actor는 시스템의 외부에 존재하게 한다. 어떤 actor들이 주어진 System과 상호작용을 하는가, 무엇을 결과로 받으려하는가, 좀더 큰 관점에서 문제를 이해하는 것
    (흔히, 우리가 설계하려는 System 을 Black Box로 본다고 한다.)

비즈니스 목적을 달성하기 위해 사용자가 어떻게 시스템을 사용할 것인지를 알기 위함_

  • Domain Model
    System 내부적으로 어떤 요소(Concept)들이 존재하고 그 Concept들이 서로 어떤 상관관계(Connections)를 가지는가에 초점을 둔다.
    (즉 System 내부에 초점을 맞춘다.)

System이 내부적으로 어떻게 동작할 것인지에 대해 이해가위한 목적이다._

Use Case를 먼저 명세한 다음 다음과 같은 작업을 해야한다 .

Domain Modeling

  1. UseCase에 대하여 각 UseCase의 책임,역할이 무었인지 명세한다.
  2. 그 명세로부터 Boundary conceptinternal concept로 나눈다.
  3. internal concept들에 대하여 type( 구체적인 Action type(D), 정보를 담고있는 type(K))인지 분리한다.
  4. 이제 분리한 Concept들을 (Entity Controll Boundary pattern)으로 파악한다.
    ( 각 Concept들의 Generallization의 정도는 해당 Concept들을 어느정도까지 깊게 이해할지에 의존한다.)
  5. Concept들의 Connection들을 찾아 하나의 Assocaition(상관관계)을 만든다.
  6. 각 Concept들의 Attribute를 찾아낸다. ( 해당 Concept는 어 정보를 필요로 하고 해당 정보의 의미가 무었인지)
  7. Domain Model을 그린다.
  8. 그 Concept가 소비되는 UseCase가 무었인지 역추적 (Tracability Matrix 적용), 각각의 Use Case가 어떤종류의 사전,사후조건이 필요로할 것인지 명세한다.

주의할점

  1. 고객이 요구하지않는 부분에 대해서는 기능을 마음대로 추가하면 안됌
  2. 실제 세계의 제약들과 문제들을 간과하면 안된다
    ex: I,O device 경제적 법적문제들, network등등
  3. 모듈에 대한 input ,outdata를 빠뜨리면 안된다.
  4. 요구분석간의 의존석을 간과하면 안된다.
  5. 각 모듈별로 동일한 데이터가 들어가고 동일한 아웃풋이 들어갈거라 생각하면 안된다. 각 모듈별에는 각각의 Data가 들어감

설계

  1. Assign Responsibility
    요구분석의 결과(User Case, Domain Model)를 통해 얻은 Concept들에 대하여 각 컨셉트들에 대해 대응하는 Responstibility를 찾아내서 부여함.

    • Responsibility 종류
      Doing (정보처리)
      Knowing (정보유지)
      Communicating (정보전달)
  2. Concept Connect
    Use Case의 Flow of Event 각 항목으로부터 발생할 수 있는 모든 Variation에 대해 생각한다.
    그런 Variation에 대해 어떤 Solution을 채택할지는 어떤 디자인원칙을 사용할지에 대해 다른데, 이는 선택의 문제이다. 여러대안들중에 고객의 요구를 가장 잘 해결할 수 있을만한 대안을 선택하는 것이 중요하다. 이는 따로 공식이 있지않고 상황에 따라 달라 많은 체험적 지식으로부터 알 수 있다.

    보통 객체별로 책임을 완전히 분리하여 해당 일을 전문적이게 하는 객체에게 일을 넘기는 방식을 지향한다. 하나의 객체가 여러가지의 책임을 가지면 확장성이 매우 떨어진다.

    확장성은 보통 기능이 수정,추가될때 코드에 전체적인 변화량에 의해 판단되어진다. 어떤 기능을 수정하게 될때, 코드의 전체적인 부분에 수정이 가해지면 확장성이 떨어진다고 볼 수 있다.

  3. 문서화

    선택한 Solution에 대해 reasoning process를 다큐먼트해야함

    (설계자가 고려했던 대안들에 대해 충분히 문서화시켜서 결론적으로 왜 이 Solution을 채택하게 되었는지를 문서화시키는 것이 중요)

  4. Object Sequence Diagram 과 Class Diagram

    Object Sequence Diagram을 그린후에 Responsibility 가 있는 Object들끼리 어떤 상관관계가 있는를 그림으로 나타냄(Class Diagram)

    OSD: 시스템 내부에 동작한 Object들이 어떻게 연결되어 있는지에 대한 그림

테스팅

테스팅의 목적은 어떻게하면 적은 비용으로 가장 많은 오류를 검출할 수 있도록 테스트를 할 것인가?이다.

그리고 어떠한 테스팅을 하냐에 따라 얼마나 오류를 적은 비용으로 잘 검출했는지가 달라질 수 있음을 유의해야 한다. 단순히 많은 테스트케이스를 검사했다고 test coverage가 높다고 말할 수 가없다.

어차피 테스팅을 아무리 잘한다해도 우리는 시스템이 어떤 오류도 없이 잘 돌아갈 수 있음을 보장할 수 없다.
결국 체계화되고 잘 설계된 테스트케이스를 선별함으로써 굳이 테스트 해보지 않아도 선별된 테스트케이스(critical test)를 통과하면 자동으로 그 테이트도 통과할 수 있음을 기대하고 어떤 테스트를 수행할지 우선순위를 정해야한다.

  • Logical Organization of Testing
    • 단위테스트
    • 통합테스트
    • 시스템테스트
      • 기능테스트
      • 비기능테스트
      • 요구사항테스트 : 사용자 요구분석후에 생각해낼 수 있는 테스트
      • 설치테스트 : 사용자 환경에서 테스트 고려

Heuristic(경험적 지식) for acheiving high coverage

  • black box testing( 코드를 직접 보지않고도 생각해낼 수 있는 테스팅, 입력데이터에 초점)

    • Equivalence testing

      입력데이터 종류와 범위를 미리 안다고 치면,데이터를 어떤식으로 뽑아야 오류를 검출해낼 수 있는지를 알 수 있음

      모듈의 명세서를 통해 해당 기능에서 어떤 데이터를 받는지 확인한 다음,해당 데이터의 범위 경계선,밖을 기준으로 데이터를 선별해내는 방식이다 .

      보통 두 그룹으로 데이터를 나눔,해당 명세서에서 입력받는 데이터의 그룹에 속한 데이터들과 속하지 않는 데이터들

  • Boundary testing

    입력데이터들의 경계값들에 초점을 맞춤

    • zeors, min/max value, empty set, empty string, and null
    • confusion between > and ≥
  • white-box testing(코드를 정확히 이해하고 코드테스팅)

    • Control- flow testing

      소스코드의 제어흐름의 이동경로 테스트

      • 모든 소스코드를 한 번 지나치는 테스트
      • 제어가 분리되는 지점을 모두 지나쳐가는 경우의 테스트
    • State based testing

      객체지향적인지를 테스트하는 기법

profile
안경 쓴 개발자

0개의 댓글