UML 다이어그램 유형

Posted by Alvin You
2014.03.17 22:27 소프트웨어공학

유스케이스 다이어그램(use case diagram) : 응용 프로그램을 사용하는 사용자와 그들이 어떤 일을 할 수 있는지에 대한 요약 정보를 보여준다.

   

   

원본 위치 <http://www.gatherspace.com/static/use_case_example.html>

   

   

   

액티비티 다이어그램(activity diagram) : 유스케이스 다이어그램을 좀 더 상세화 한 다이어그램. 일련의 동작들을 통해 작업의 흐름으로 소프트웨어 프로세스를 보여준다.

   

   

원본 위치 <http://www.google.com/imgres?imgurl=http://i.msdn.microsoft.com/dynimg/IC276120.png&imgrefurl=http://msdn.microsoft.com/en-us/library/dd409465.aspx&h=424&w=587&sz=14&tbnid=CKHJvx7s6581bM:&tbnh=86&tbnw=119&zoom=1&docid=4BoTfUWw9MJDFM&hl=en&sa=X&ei=8O5fT_mzCO7OmAXPktyOCA&ved=0CHAQ9QEwCg&dur=0>

   

시퀀스 다이어그램(sequence diagram) : 서로 다른 개체 사이의 상호작용을 표현한다. 상호작용은 일반적으로 개체끼리 주고받는 일련의 메시지로 표현된다.

   

   

원본 위치 <http://www.google.com/imgres?imgurl=http://upload.wikimedia.org/wikipedia/en/thumb/3/32/CheckEmail.png/250px-CheckEmail.png&imgrefurl=http://en.wikipedia.org/wiki/Sequence_diagram&h=249&w=250&sz=7&tbnid=OzbPYsQ7D-M-jM:&tbnh=89&tbnw=89&zoom=1&docid=jOQJP_i-4V-dOM&hl=en&sa=X&ei=Z-9fT67QGOHYmAW_94zzBw&sqi=2&ved=0CEUQ9QEwAA&dur=1>

   

컴포넌트 다이어그램(component diagram) : 소프트웨어 시스템의 구조를 상위 수준에서 표현하는 데 사용된다.

   

원본 위치 <http://www.google.com/imgres?imgurl=http://i.msdn.microsoft.com/dynimg/IC267828.png&imgrefurl=http://msdn.microsoft.com/en-us/library/dd409393.aspx&h=264&w=403&sz=9&tbnid=cOiZJYntjuLvwM:&tbnh=81&tbnw=124&zoom=1&docid=HA5Jt4wqqv5ybM&hl=en&sa=X&ei=FPBfT8r-KdDAmQX9rK2jCA&ved=0CFEQ9QEwBg&dur=1>

   

클래스 다이어그램(class diagram) : 응용 프로그램 시스템을 구성하는 개체들을 표현한다. 클래스 다이어그램의 개체들은 시스템의 특정 구현을 참조하지는 않는다.

   

원본 위치 <http://www.google.com/imgres?imgurl=http://www.agilemodeling.com/images/models/classDiagramInheritance.jpg&imgrefurl=http://www.agilemodeling.com/artifacts/classDiagram.htm&h=337&w=628&sz=27&tbnid=KSoYgCzTk9aPrM:&tbnh=63&tbnw=118&zoom=1&docid=kcPZ8LVB3N4grM&hl=en&sa=X&ei=ZfBfT9qKBYrJmAW-z8n9Bw&ved=0CEkQ9QEwAA&dur=1>

   

레이어 다이어그램(layer diagram) : 시스템의 논리적인 아키텍처를 표현한다. 레이어 다이어그램은 개체들을 여러 그룹(또는 레이어)으로 구성하여 개체들이 수행하는 작업을 구분한다.

   

원본 위치 <http://www.google.com/imgres?imgurl=http://www.cwskinner.members.winisp.net/BlogImages/LayerDiagram_7C82/LayerDiagram.png&imgrefurl=http://blogs.msdn.com/b/camerons/archive/2008/07/11/layer-diagram.aspx&h=709&w=1045&sz=102&tbnid=FwplbsRfBm2xVM:&tbnh=90&tbnw=133&zoom=1&docid=o2chrjDVtpgFhM&hl=en&sa=X&ei=PvlfT5zFDuSziQe2uLi8Cw&sqi=2&ved=0CDkQ9QEwAw&dur=1088>

   

   

신고

'소프트웨어공학' 카테고리의 다른 글

UML 다이어그램 유형  (0) 2014.03.17
UML을 사용해야 하는 이유  (0) 2014.03.17
분기와 병합  (0) 2014.03.17
이 댓글을 비밀 댓글로

UML을 사용해야 하는 이유

Posted by Alvin You
2014.03.17 22:27 소프트웨어공학
  • UML을 사용해야 하는 이유
    • 어플리케이션으로부터 청사진을 만든다.
    • 시간과 자원을 평가하고 계획한다.
    • 팀간 그리고 팀 내에서 의사소통을 한다.
    • 프로젝트를 문서화 한다.

       

  • UML 다이어그램 유형
    • 활동 다이어그램(Activity Diagram)
    • 사용 사례 다이어그램(Use Case Diagram)
    • 시퀀스 다이어그램(Sequence Diagram)
    • 공동작업 다이어그램(Collaboration Diagram)
    • 상태표 다이어그램(Statechart Diagram)
    • 구성 요소 다이어그램(Component Diagram)
    • 배포 다이어그램(Deployment Diagram)
신고

'소프트웨어공학' 카테고리의 다른 글

UML 다이어그램 유형  (0) 2014.03.17
UML을 사용해야 하는 이유  (0) 2014.03.17
분기와 병합  (0) 2014.03.17
이 댓글을 비밀 댓글로

분기와 병합

Posted by Alvin You
2014.03.17 22:18 소프트웨어공학

분기와 병합은 소프트웨어 구성 관리(Software Configuration Management, SCM)라는 큰 주제의 단면임

SCM의 정의?

변경하려고 하는 작업 산출물을 식별하고, 그 산출물 간의 관계를 수립하고, 적용된 변경 사항을 제어하고, 만들어진 변경 사항을 감사 및 보고하는 등의 변경을 제어하기 위해 고안된 일련의 행위

   

분기 - 코드를 분기하는 가장 쉬운 방법은 복사본을 만드는 것이다. 그리고 Team Foundation Server에서 여러분이 하는 작업이 바로 파일의 복사본을 만다는 것이다. Team Foundation Server에서 파일을 분기할 때, 다른 경로에 별도의 물리적인 복사본을 만든다. 그러고 나서야 이 분기에 작업할 수 있고, 병합할 준비가 되면 원본 폴더에 변경 사항을 병합할 수 있다.

   

병합 - 이것은 다른 모든 분기를 취하여 하나의 코드 베이스로 다시 합치는 프로세스이다.

  • 정방향 통합 : 부모 분기에 만들어졌던 변경 사항을 자식 분기에 밀어 넣기 위해 부모 분기의 코드를 자식 분기에 병합하는 것
  • 역방향 통합 : 자식 분기에서 만들어진 모든 변경 사항을 부모 분기로 당겨 오기 위해서 자식 분기에서 부모 분기로 코드를 병합하는 것

   

기본 버전이 없는 병합 - 서로에게 직접 분기되지 않은 병합 항목의 프로세스이다. 이 프로세스를 TFS 2010에서 사용할 수 있지만, 혼란스러운 많은 충돌을 야기할 수 있고, 일반적으로 좋은 사례로 여겨지지 않는다.

   

릴리즈 - 몇 가지 점에서, 코드를 개발 환경에서 다음 단계로 옮기기 원할 때, 품질 보증 또는 일반적인 릴리즈를 한다. 릴리즈는 품질 보증 테스트 또는 고객에게 제공 등의 특정 목적으로 코드를 배포하는 것으로 정의한다.

   

   

일반적인 분기 전략

  • 분기하지 않기 : 이 전략은 같은 코드 베이스에 지속적으로 작업하고 한 번에 하나의 응용 프로그램 버전을 출시하고 지원하는 작은 팀에게 적합하다.

    분기의 주된 이점은 코드 베이스에 병렬 개발을 할 수 있다는 것이다. 1인 개발 기업일지라도 여기 언급된 다른 분기 전략들이 도움이 될 수 있다.

       

       

  • 릴리즈별 분기 : 각각의 소프트웨어 릴리즈는 그 릴리즈만의 분기가 있다. 릴리즈별 분기는 사람들이 특정 릴리즈에 대한 소스 코드를 레이블링하는 개념에 익숙한데다 거기서 단지 한 발짝 더 나아간 것뿐이므로 이해하기 쉽다. 특정 버전이 구동되고 있는 응용 프로그램의 코드를 쉽게 얻을 수 있고, 정해진 시간에 응용 프로그램 버전이 하나 이상 운영되어야 하는 조직에 적용하면 좋다.
  •    

  • 코드 승격 분기 : 이 분기 모델은 한 번에 하나의 응용 프로그램 버전을 가지는 통제된 환경에 아주 적합하다. 이 모델은 Test 분기에서 안정화가 일어나고 있는 동안 Dev 분기에서 개발을 지속할 수 있게 해준다. 그리고 운영 환경에 옮겨진 변경 사항에 대한 아주 높은 수준의 시각화를 제공한다.

       

       

  • 기능별 분기 : 기능별 분기는 특정 기능을 별도의 분기로 분리시키는 데 사용된다. 그렇게 함으로써 다른 기능들과 중복되는 것을 방지한다.

    기능별 분기는 큰 팀이 큰 코드 베이스에서 작업하기에 적합한 경향이 있다. 작은 팀과 작은 코드 베이스들에게는 기능을 구현할 때의 격리의 어려움, 특정 기능을 만들기 위한 자원의 부족, 때때로 병렬로 작업하여 얻었던 이득을 상쇄하는 코드의 병합 문제를 떠안아야 한다는 것을 의미한다.

       

신고

'소프트웨어공학' 카테고리의 다른 글

UML 다이어그램 유형  (0) 2014.03.17
UML을 사용해야 하는 이유  (0) 2014.03.17
분기와 병합  (0) 2014.03.17
이 댓글을 비밀 댓글로