Architectural Design

[About architectural design]

• Designing the overall structure of a SW system.
• Identifying the main structural components in a system and the relationships between them.
• Designing a system organization that will satisfy the functional and non-functional requirements of a system.
• Depending on the system type, the background and experience of the system architect, the specific requirements for the system.

[The architecture of a packing robot control system]

• Block diagram
  • Box (Boxes within boxes): A component (or sub-components)
  • Arrow: The flow of data or control signals from component to component.
    

[SW architectures at 2 levels of abstraction]

• Architecture in the small (Today's topic)

  • The architecture of individual programs.
    

• Architecture in the large (system of systems)

  • The architecture of complex enterprise systems that include other systems, programs, and program components.

[3 Adavantages for designing SW architecture]

• Stakeholder communication

  • The architecture can be used as a focus for discussion by different stakeholders.

• System analysis

  • Architectural design decisions can affect whether the system can meet critic al requirements such as performance, reliability, and maintainability.

• Large-scale reuse

  • The system architecture can support large-scale software reuese.
    (The system architecture is often the same for systems with similar requirements.)

Architectural Design Decisions

Non-functional requirements.

• Constraints on the services offered by the system.
  

  • Performance

    • Localize critical operations within a small number of components.
      (The smae computer > distributed across the network)
      중요 작업을 소수의 구성 요소 내에서 집중시킴

    • Reduce the number of component communications by using large components.
      큰 구성 요소 사용으로 구성 요소 간 통신 수를 감소시킴

  • Security

    • Use a layered structure for the architecture.
      (= Protecting the most critical assets in the innermost layers.)
      아키텍처에 계층 구조 사용

  • Safety

    • Reduce the costs and problems of saftey validation.
      (e.g., Putting saftey-related operations together in a single component.)
      안전 관련 작업을 한 구성 요소 내에서 집중시킴으로써 안전 검증 비용을 줄이고 문제를 감소시킴

  • Availability

    • Include redundant components to replace and update components without stopping the system.
      중단 없이 구성 요소를 대체하고 업데이트하기 위한 중복 구성 요소 포함

  • Maintainability (유지보수성)

    • Use fine-grain, self-contained components that my readily be changed.
      변경 가능한 미세한 구성 요소 사용

    

Architectural Views (4+1 views)

[Architectural views]

• What views or perspectives are useful when designing and documenting a system's architecture?
  -> The "4+1" view model of software architecture
  

  • A logical view

    • which shows the key abstractions in the system as objects. (functional requirements).
      시스템의 핵심 추상화 요소를 보여줌. 주로 funtional 요구사항을 다루며, 시스템 내 객체들 간의 상호 작용을 나타냄. 시스템의 논리적인 구조를 표현

  • A process view

    • which shows how, at run-time, the system is composed of interacting processes. (non-functional requirements: performance)
      시스템이 실행될 때 상호 작용하는 프로세스로 시스템을 구성하는 방식을 보여줌. 주로 non-functional 요구사항 중 성능과 관련된 측면을 다루며, 시스템의 동작 및 프로세스 간 상호 작용을 설명함

  • A development view (= A implementation view)

    • which shows how the software is decomposed for development.
      (Useful for software managers and programmers)
      소프트웨어가 개발될 때 어떻게 분해되고 구성되는 지를 보여줌. 주로 소프트웨어 관리자와 프로그래머들을 위한 뷰로, 시스템의 소프트웨어 구조와 모듈화를 다룸

  • A physical view

    • which shows how the system HW and SW components are distributed across the processors in the system. (systems engineers)
      시스템의 하드웨어와 소프트웨어 구성 요소가 시스템 내 프로세서에 분산되는 방식을 보여줌. 시스템 엔지니어들을 위한 뷰로, 시스템의 물리적 배치와 구성을 나타냄

  • Scenarios

    • which shows the sequences of interactions between objects or between processes.
      객체나 프로세스 간 상호 작용의 일련의 시퀀스를 보여줌. 시나리오는 다양한 뷰 간의 관계와 시스템 작동 방식을 묘사하는 데 사용됨

Architectural Patterns

[Architectural Patterns]

• A stylized, abstract description of good practice, which has been tried and tested in different systems and environments.

• Describing a system organization that has been successful in previous systems.

• Including information on when it is and is not appropriate to use that pattern, and details on the pattern's strengths and weaknesses.

1. Model-View-Controller (MVC) pattern

• Separate 1)presentation and 2)interaction from the system data.
  

• The system is structured into 3 logical components that interact with each other.

  • Model component
    • manages the system data and associated operations on that data.
  • View component
    • defines and manages how the data is presented to the user.
  • Controller component
    • manages user interaction (e.g., key presses, mouse clicks, etc.) and passes theses interactions to the View and the Model.

• When used?

  • There are multiple ways to view and interact with data. (Web, mobile app, ...)
  • The future requirements for interaction and presentation of data are unknown.

• Advatages

  • Allow the data to change independently of its representation and vice versa.
  • Support presentation of the same data in differenct ways.

• Disadvantages

  • Involve additional code and code complexity when the data model and interactions are simple.

2. Layered Architecture

• Organizing the system into layers, where each layer provides services to the layer above it.
  

• Achieving separation and independence.

• Supporting the incremental development of systems.

  • Some of the services provided by each layer are available to users.
  • Only the adjacent layer is affected where layer interfaces change.

• When used?

  • When building new facilities on top of existing systems.
  • When several teams develop a system and each team is responsible for a layer of functionality.
  • When there is a requirement for multi-level security.

• Advantages

  • Allowing replacement of entire layers so long as(만약 ~하는 한) the inferface is maintained.
  • Redundant facilities (e.g., authentication) can be provided in each layer to increase the dependability of the system.

• Disadvantages

  • Providing a clean separation between layers is often difficult.
  • Not interacting directly with lower-level layers rather than through the layer immediately below it.
  • Performance can be a problem because of multiple levels of interpretation of a service request as it is processed at each layer.

  

3. Repository Architecture

• All data is managed in a repository accessible to all system components.

• Components do tno interact directly, only through the repository.
  

• When used?

  • When having a system in which large volumes of information are generated that has to be stored for a long time.
  • Data-driven systems where the inclusion of data in the repository triggers an action or tool.

• Advantages

  • Components can be independent;
    (Don't need to know__ of the existence of other components.)
  • All data can be managed consistently as it is all in one place.

• Disadvantages

  • The repository is a single point of failure so problems in the repository affect the whole system.
  • May be inefficiencies organizing all communication through the repository.
  • Distributing the repository across several computers may be difficult.

4. Client-Server Architecture

• The system is presented as a set of services, with each service delivered by a separate server. (Youtube, Netflix, ...)
• Clients (e.g.,s users of these services) access servers to make use of them.
  

[The major components of Client-Server Architecture]

• A set of servers that offer services to other components.

  • ex) Print servers that offer printing services.
  • ex) File servers that offer file management services.

• A set of clients that call on the services offered by servers.

• A network that allows the clients to access these services.

• When used? (Youtube, Netflix, ...)

  • Used when data in a shared DB has to be accessed from a range of locations.

• Advantages

  • Servers can be distributed across a network.
  • General functionality (e.g., a printing service) can be available to all clients and does not need to be implemented by all services.

• Disadvantages

  • Each service is susceptigble to denial of service (DoS) attacks or server failure.
  • Performance problems as it depends on the network.
  • Management problems if servers are owned by different organizations.

  

5. Pipe and filter Architecture

• The processing of the data is organized so that each processing component (filter) is discrete and carries out one type of data transformation.
  각 처리 구성요소(필터)가 독립적이며 데이터 변환의 한 유형을 수행함

• The data flows (as in a pipe) from one component to another for processing.
  데이터는 파이프처럼 한 구성요소에서 다른 구성요소로 흐름

• When used?

  • Commonly used in data-processing applications where inputs are processed in separate stages to generate related outputs.
    주로 데이터 처리 응용 프로그램에서 사용됨. 입력 데이터가 관련된 출력 데이터를 생성하기 위해 각 단게별로 처리되어야 하는 경우에 자주 사용됨
    

• Advantages
  • Easy to understand and supports transformation reuse.
  • Workflow style matches the structure of many business processes.
  • Evolution by adding transformations is straightforward.
• Disadvantages
  • The format for data transfer has to be agreed between communicating transformations.
  • It can not reuse architectural components that use incompatible data structures.

Application Architectures

[Application Architectures]

• Application systems used by the businesses have much in common.
  비즈니스에서 사용되는 애플리케이션 시스템들은 많은 공통점을 가짐

• Application architectures encapsulate the principal characteristics of a class of systems.
  애플리케이션 아키텍처는 특정 시스템 클래스의 주요 특성을 캡슐화함

  • Real-time system (e.g., data collection systems or monitoring systems)

• Use case of application architecture models.

  • As a starting point for architectural design process.
    아키텍처 설계 프로세스의 시작점으로 사용

  • As a design checklist.
    디자인 체크리스트로 사용

  • As a way of organizaing the work of the development team.
    개발 팀의 작업을 조직하는 방법으로 사용

  • As a vocabulary for talking about application types.
    (Using the concepts identified in the generic architecture.)
    애플리케이션 유형에 대해 이야기할 때 사용 (일반 아키텍처에서 식별된 개념 사용)

[The architectures of 2 types of application]

• Transaction processing applications

  • Database-centered applications that process user requests for information and update the information in a database.
  • The most common types of interactive business systems.
    ex) Interactive banking systems, e-commerce systems, booking systems.

• Language processing systems

  • Systems in which the user's intentions are expressed in a formal language, such as a programming language.
  • Processing the language into an internal format and interpreting this internal representation.
    ex) Compilers (high-level language programs -> machine code).

Transaction processing systems

• Processing user requests for information from a database, or requesting to update a database.

• A transaction

  • Any coherent sequence of operations that satisfies a goal.
    ex) "find the times of flights from Seoul to Pittsburgh :)"
    ex) "a customer request to withdraw money from a bank account using an ATM"

[The software architecture of an ATM system]

• Transaction processing systems can be organized as a "pipe and filter architecure", with system components.
  • 2 components: ATM software and the account processing software (Database랑 연결되는듯).
    

[About Information systems]

• All systems that involve interaction with a shared database.
• Web-based systems, where the user interface is implemented in a web browser.
• The Information system is modeled using a layered approach.
  - The top layer (e.g., user interface)
  - The bottom layer (e.g., system database)
  
  

Language processing systems

• Translate one language into an alternative representation of that language.
• Compiler
  • Trnaslate a program written in one language ("source language") into a program written in another language ("target language")
    

Front End of Modern Compilers

• The lexical analyzer transforms the character stream into a stream of tokens.
• The syntax analyzer transforms the stream of tokens into a syntax tree.
• The semantic analyzer check if the program is semantically well-formed.
• The IR translator traslate the syntax tree into IR.
  

Lexical Analyzer

1. The lexical analyzer transforms the character stream
   
2. into a sequence of lexemes
   
3. and then produces a token sequence (pair of Token name, Token value).
   

Syntax Analyzer

1. The parser transforms the sequence of tokens (One-dimension)
   
2. into the syntax tree: (Two-dimension)
   

Semantic Analyzer

• ex) Type errors:
  
• Other semantic errors:
  • array out of bounds
  • null-dereference
  • divide-by-zero

IR Translator

• Intermediate Representation (IR):
  • lower-level than the source language
  • high-level than the target language
• ex) translate the syntax tree into three-address code:
  

Summary