Documenting an architecture is a matter of documenting the relevant views and then adding documentation that applies to more then one view

 

1. Architectural View의 진화

Parnas(1974) observed Software consists of many structures, which he defined as partial descriptions showing a system as a collection of parts and showing relations among the parts

Perry and Wolf(1992) recognized that similar to building architecture, a variety of views of a system are required. Each view emphasizes certain architectural aspects that are useful to different stakeholders or for different purposes.

Kruchten(1995, Rational Software Co) wrote an influential paper describing 4 main views of software architecture

  • logical view
  • process view
  • development view
  • physical view And Kruchten prescribe using a small subset of important scenarios(instances of use-cases) that is the “+1” view called
  • use-case view

    2. Model, View and Viewpoint

    MODEL

    A simplification of reality created in order to better understand the system being created. A complete description of a system from a particular perspective (with a particular purpose) and at a specific level of abstraction. “Complete” in this context means that you don't need any additional information to understand the system from that perspective. There is no single model (schematics) of an architecture. There are many models each representing an important aspect of the architecture. A model contains a set of model elements organized in some way. Two models cannot overlap. Some examples of models include: Analysis Model, Design Model, and Implementation Model.

    VIEW

    A simplified description/abstraction/projection of a model, which is seen from a given perspective or vantage point, and omits entities that are not relevant to this perspective.

    Views can be tailored to address a stakeholder’s concern(s).

    Views are relative to the needs of stakeholders, those individuals materially affected by the outcome of the system. This includes customers, users, architects, designers, developers and development managers, field support and systems support, etc.

    VIEWPOINT

    A definition (or description) of a view. The content, meaning and representation of a view. A viewpoint establishes the conventions by which a view is created, depicted and analyzed. The viewpoint determines the languages (including notations, modeling techniques, etc.) to be used to describe the view, and any associated modeling methods or analysis techniques to be applied to these representations of the view.

    3. RUP 4+1 View

    RUP에서 5개의 View가 필수는 아니고 단지 권고사항일 뿐이다. 따라서 필요하면 다른 View추가할 수 있다.


    Sample: Non-Functional Requirements View
     

    4. Siemens 4 View

    Siemens에서 정의한 S/W아키텍쳐 View로써 많은 문헌에서 참조되고 있다.

     

    5. 비즈니스 컴포넌트 팩토리(1999)

  • Technical Architecture

    Component 실행 환경, 개발툴, 사용자 인터페이스 Component based시스템을 개발 실행하기 위해 필요한 기술적 문제

  • Application Architecture

    아키텍쳐적 결정, 패턴, 가이드라인, 표준 등을 다룸

  • Project management Architecture

    Large 시스템을 위한 Large Team을 셋업하고 관리하기 위한 개념, 가이드라인, 원리 등을 기술

  • Functional Architecture

    시스템의 기능 명세와 구현 등의 문제를 다룸



  • Posted by sjokim
    ,