[Software Engineering] 11주차 (2)

Process Specification

 

shows process details which are implied but not shown in a DFD

• Specifying the input, output, and algorithm of a module in a DFD
• Normally written in pseudo-code or table format
• Specifying all (upper/lower) processes in DFD hierachies

프로세스 스펙 또한 DFD, SA에 포함되어야한다. 이는 DFD에 나타나지 않은 프로세스의 디테일을 보여준다.

 

Example: Left Sensor Interface

 

Data Dictionary

 

Defines data elements to avoid different interpretations

• Often uesd in a simple form like below

 

Example:

 

Entity Relationship Diagram (ERD)

 

A graphical representation of the data layout of a system at a high level of abstraction

• Defines data elements and their inter-relationship in the system
• Similar with the class diagram in UML

시스템의 데이터들의 배치를 높은 추상화 단계에서 그래픽하게 나타내는 것으로, UML의 class diagram과 유사하다.

 

State Transition Diagram

 

Shows the time ordering between processes

• More primitive than Statecharts Diagram in UML
• Different from the State transition diagram (FSM) used in DFD
• Similar with the UML Activity Diagram
• Not widely used now

프로세스 사이의 순서를 나타내는 것으로, FSM과는 다르고, UML activity diagram과 유사하다.

 

Structure Design

 

Needs transform analysis

• No data comes, being processed, and goes out by inself
• Somebody should call input/output processes to do something

transform분석이 필요한데, 프로세스에 의해 처리되지, 데이터 그 자체로 들어오고 나가지 않는다. 누군가는 무언가를 하기 위해서 프로세스를 호출해야하기 때문이다. 이렇게 데이터를 변형하는 프로세스에 대한 분석이 필요해졌다.

 

Needs to design functional decomposition according to SA

• Information hiding
• Modularity
• Low coupling
• High internal cohension

SA에 따라서 기능적인 분해를 디자인할 필요가 생겼다.

 

Many models were proposed, but now widely used except Structured Charts

많은 모델들이 제시되었지만, Structured Charts를 제외하고는 잘 사용되지 않는다.

 

Example of Tranform Analysis:

Transform Analysis

Transform Analysis

 

Example of Structured Charts:

Structured Charts

 

Architectural Design

 

Architectural Design is concerned with understanding how a software system should be organized and designing the overall structure of that system

• A critical link between requirements engineering and design
• Identifies the main structural components in a system and the relationships between them

아키텍처 디자인은 어떻게 소프트웨어 시스템이 조직화되야하고, 그 시스템의 전체적인 구조를 어떻게 디자인해야 하는지에 집중한다. 요구공학에서 추출된 요구사항과 디자인 사이의 중요한 연결다리로서, 주된 구조적 컴포넌트들과 그들 사이의 관계를 나타낸다.

 

Architecture model describes how the system is organized as a set of communicating components

아키텍처 모델은 어떻게 그 시스템이 서로 영향을 주고 받는 컴포넌트로서 구성되는지를 설명한다.

 

Example of high level architecture design:

The architecture of Packing Robot Control System

 

Architectural Abstraction

 

Architecture in the large

• Concerned with the architecture of complex enterprise systems that include other systems, programs and program components
  • Enterprise systems are distributed over different computers, which may be owned and managed by different companies

아키텍처의 추상화는 아키텍처의 레벨, 크기를 의미하는데, 큰 규모의 아키텍처는 일반적으로 다른 시스템들이나 프로그램들 등을 포함하는 복잡한 기업용 시스템의 아키텍처를 말한다.

 

Architecture in the small

• Concerned with the architecture of individual programs
• Concerned with the way that an individual program is decomposed into components

작은 규모의 아키텍처는 개인 프로그램의 아키텍처를 의미하는데, 이는 프로그램 자체를 컴포넌트들로 분해하는 방법에 집중한다.

 

Advantages of Architectural Design

 

Stakeholder communication

• Architecture may be used as a focus of discussion by system stakeholders

System analysis

• Analysis of whether the system can meet its non-functional requirements is possible

Large-scale reuse

• The architecture may be resuable across a range of systems
• Product-line architectures may be developed

아키텍처 디자인은 다음의 3가지 장점이 있다:

1. 이해관계자들과의 의사소통을 도와줄 수 있다.
2. 비기능 요구사항을 충족할 수 있는지 등을 분석할 수 있다. 일반적으로 비기능 요구사항이 아키텍처에 중요하기때문에 역으로 아키텍처를 디자인하면 비기능 요구사항을 충족시킬 수 있는지를 알 수 있다. Architecture significant requirement, ASR은 아키텍처에 중요한 영향을 끼치는 요구사항을 말한다
3. 큰 규모의 재사용에 장점이 있다.

 

Architectural models

 

Representation of architecture models

• Simple, informal block diagrams
• Box and Line diagram
• Extensions of UML models

아키텍처 모델을 표현하는 방법으로는 다음과 같은 방법들이 있다. 이때 UML의 확장에 대해서는, 일반적으로 UML은 객체지향을 위한 diagram이다. 따라서 OO가 아닌 언어의 아키텍처를 디자인하기 위해서는 UML의 기능을 확장해서 사용해야한다.

 

Use architecture models

• As a way of facilitating discussion about the system design
  • A high-level architectural view of a system is useful for communication with system stakeholders and project planning because it is not clutterd with detail
  • Stakeholders can relate to it and understand an abstract view of the system. They can then discuss the system as a whole without being confused by detail
• As a way of documenting an architecture that has been designed
  • To produce a complete system model that shows the different components in a system, their interface and their connections

시스템 디자인에 대한 건설적인 토론의 방법으로서 아키텍처 모델을 사용할 수 있다. 또한 어떻게 디자인 되었는지에 대한 문서로서 이를 사용할 수도 있다.

 

Architectural Representations

 

Simple, informal block diagrams

• Showing entities and relationships simply
• The most frequently used method for documenting software architectures
• However, lack of semantics do not show the types of relationships between entites nor the visible properties of entities in the architecture
• The semantics of architectural models depend on how models are used

간단한 다이어그램의 경우는 개체와 그 관계들이 간결하게 표현되어있고, 소프트웨어 아키텍처를 문서화하는데 가장 널리 쓰이는 방법이다. 하지만 적은 양의 문법은 많은 종류의 관계나 개체들을 표현하는데 한계가 있을 수 있다.

 

Box and Line diagram

• Very abstract - not show the nature of component relationships nor the externally visible properties of the sub-systems.
• However, useful for communication with stakeholders and for project planning

박스와 선 다이어그램의 경우 매우 추상화된 방법인데, 이는 컴포넌트 관계의 본질을 보여주지 않고, 부분 시스템의 외부적인 특징또한 볼 수 없다. 하지만, 이해관계자들과의 의사소통이나 프로젝트 계획단계에서 유용하게 사용된다.

 

Extensions of UML models

• Extending component diagrams including class diagrams, object diagrams, composites structure diagrams.
• Not widely uesd yet

UML모델의 확장은 클래스 다이어그램등을 확장해서 사용하는 것인데, 잘 사용되지는 않는다.

 

Architectural Design Decisions

 

Architectural design is a creative process

• The design process differs depending on the type of system being developed

아키텍처 디자인은 창의적인 과정으로 이는 시스템이 계발되는 종류에따라 디자인 과정이 달라질 수 있기 때문이다.

 

However, several common design decisions span all design processes

• After the non-functional characteristic of the system

하지만 여러가지 일반적인 디자인 선택들이 모든 디자인 과정에 걸쳐 존재한다.

 

Architecture and System Characteristics

 

Perfomance

• Localize critical operations and minimize communications. Use large rather than fine-grain components

Security

• Use a layerd architecture with critical assets in the inner layers

Safety

• Localize safety-critical features in a small number of sub-systems

Availability

• Include redundant components and mechanisms for fault tolerance

Maintainability

• Use fine-grain, replaceable components

이 5가지 특징들을 포함하는 QA들은 아키텍처 디자인단계에서 고려하지 않는다면, 나중에 적용하기가 굉장히 힘들다.

 

Architecture Reuse

 

Systems in the same domain often have similar architectures that reflect domain concepts

• Application product lines are built around a core architecture with variants that satisfy particular customer requirements

같은 영역에서의 시스템은 도메인 개념에 의해 영향을 받는 비슷한 아키텍처를 종종 사용한다.

 

The architecture of a system may be designed around one of more architecture patterns ro architecture styles

시스템의 아키텍처는 여러 아키텍처 패턴이나 아키텍처 스타일들 중 하나로 디자인 될 수 있다. 즉 아키텍처 패턴이나 스타일은 일종의 building block으로서 역할을 할 수 있다.

 

Architectural views

 

Each architectural model only shows one view showing

• How a system is decomposed into modules,
• How the run-time processes interact, or
• Which system components are distributed across a network

We need to multiple views of the software architecture for both design and documentation purposes

• What views are useful when designing and documenting a system's architecture?
• What notations should be used for describing architectural models?

각각의 아키텍처 모델은 하나의 관점으로만 볼 수 있는데, 예를 들어, 어떻게 시스템이 모듈로 분해될 수 있을까. 어떻게 실행시간에 프로세스들이 상호작용할까. 등등. 그렇기 때문에 우리는 디자인과 문서화를 위해 다양한 관점으로 아키텍처를 봐야한다.

 

4+1 View Model of Software Architecture

 

• Logical View: showing the key abstractions in the system as objects or object classes → static view로서 class diagram등을 통해 표현할 수 있다.
• Process View: showing how, at run-time, the system is composed of interacting processes → dynamic view로서 sequence diagram등을 통해 표현할 수 있다.
• Development View: showing how the software is decomposed for development → 개발의 관점으로서 component diagram등을 통해 표현할 수 있다.
• Physical View: showing the system hardware and how software components are distributed across the processors in the system → hardware view로서 UML Diployment diagram등을 통해 표현할 수 있다.
• Related 4 views with use cases or scenarios → 이는 4가지 관점을 한 번에 볼 수 있다.

Representing Architectural Views

 

Unified Modeling Language (UML) is a candidate notation for describing and documenting system architectures

• Component diagram, Package diagram, Class diagram, etc.
• However, UML does not include abstractions appropriate for high-level system desciption

UML은 아키텍처를 문서화하고 표현하는 여러 후보 표기법들 중 하나이다. 하지만 이는 높은 단계의 표현에 대해서는 적절하지 않다는 단점을 갖는다.

 

Architectural Description Languages (ADLs) have been developed, but not widely used yet.

ADLs이라는 것이 개발되긴 했지만, 잘 사용되지는 않는다.

 

Naive diagrams have been widely uesd

단순한 다이어그램이 가장 널리 사용된다.

 

Example:

Naive Diagram with Key or Legend

 

Describing Software Architectures

 

ISO/IEC/IEEE 42010:2011 "System and Software Engineering - Architecture Description"

• Specifies the requirements for (to be an) architecture descriptions (AD)

위 문서는 AD가 되기 위한 필수적인 요구사항들을 정리한 문서이다. 이는 Architecture가 어떤 것인지에 대해 설명이 되어있어야 하고 (기술문서) 왜 이런 Architecture가 나왔는지, 왜 이것을 선택했는지를 설명할 수 있어야한다. 이는 SRS의 QA를 기준으로 설명되어야한다.

 

Key Principles of the Architecture Description Standard

• AD should demonstrate how an architecture meets the needs of the system's diverse stakeholders → AD는 다양한 이해관계자들의 요구를 이 아키텍처로 어떻게 충족시켰는지를 보여야한다.
• The architectural concerns of the divers stakeholders can be addressed by an AD constructed with multiple architecture views of the system, where each view covers a subset of those concerns → 다양한 이해관계자들의 구조적인 걱정, 관심사를 그런 관심사들을 다루는 시스템의 다양한 아키텍처 관점으로 구성된 AD가 해결할 수 있어야한다.
• The rules for well-formedness, completeness and analyzability of each architecture view should be explicit via architecture viewpoint → 아키텍처의 관점을 통해 각 아키텍처의 완성도나 분석가능성들의 규칙들이 들어나야한다.

 

Architectural Patterns

 

A stylized description of good design practice, which has been tried and tested in different environments

좋은 디자인 활동을 개념화한 것으로 이는 각기 다른 환경에서 시도되고 테스트되었다.

 

Include information about when they are and when they are not useful

이는 이 아키텍처가 언제 좋고 나쁜지에 대한 정보를 가지고 있다.

 

Examples: A series of POSA

• MVC (Model-View-Controller)
• Layered
• Repository
• Client-Server
• Pipe & Filter
• ...