Model-Driven Engineering
Model-Driven Engineering (MDE)
- An approach to software development where models rather than programs are the principle outputs of the development process
- The programs executing on a hardware/software platform are generated automatically from the models
- Software engineers no longer should be concerned with programming language details or the specifics of execution platforms
MDE는 프로그램 대신 모델이 개발 생산물의 기준이되는 개발에서 사용하는 접근법입니다.
모델로부터 하드웨어/소프트웨어 플랫폼에서 실행되는 프로그램이 생성됩니다. 이를 통해 소프트웨어 공학자들은 더 이상 프로그래밍 언어의 디테일이나 실행환경에 대해 걱정하고 신경쓸 필요가 없어집니다.
MDE is still at an early stage of development
- Advantages
- Allows systems to be considered at higher levels of abstraction
- Generating code automatically means that it is cheaper to adapt systems to new platform
- Disadvantages
- Models for abstraction are not necessarily right for implementation
- Savings from generating code may be outweighted by the cost of developing translators for new platforms
MDE는 아직 초기 수준입니다.
시스템을 높은 수준의 추상화 레벨에서 볼 수 있고, 코드를 자동으로 생성하기 때문에 새로운 플랫폼에 시스템을 적용시키는 비용이 줄어든다는 장점이 있습니다.
하지만, 추상화를 위한 모델이 반드시 구현에 적합한 것은 아닐 수도 있다는 점, 모델로부터 생성된 코드를 만듬으로써 생기는 절감효과보다 새로운 플랫폼에 시스템을 적응시키기 위한 변환기를 만드는 비용이 더 클 수도 있다는 단점이 존재합니다.
Model-Driven Architecture
Model-driven architecture (MDA) is a model-focused approach to software design and implementation
- The precursor of more general MDEs
- Models at different levels of abstraction are created
- From a high-level, platform independent model, it is possible, in principle, to generate a working program without manual intervention
- CIM (Computation Independent Model)
- PIM (Platform Independent Model)
- PSM (Platform Specific Model)
- Often use a subset of UML models to describe a system
MDA는 소프트웨어 디자인과 구현을 위한 모델에 집중화된 접근방식입니다.
MDE의 선구자로, 서로 다른 추상화 단계에 따른 모델들을 만듭니다.
높은 추상화 단계의 모델과 플랫폼 독립적인 모델로부터 매뉴얼적인 간섭 없이 작동하는 프로그램을 만들 수 있습니다.
CIM은 시스템의 기능적 요구사항들을 나타내며, 시스템이 운영될 환경이나 상호작용들을 나타내는 모델입니다. 이는 이름에서 알 수 있듯 구현에 대한 구체적인 언급을 제외하고, 사용자의 요구사항들과 비지니스 관점에서의 시스템에 이해를 돕습니다.
PIM은 특정 플랫폼과 독립적으로 시스템의 구조와 동작을 모델링하는 것입니다. PIM은 주로 UML를 이용해 나타내는데, 정적인 구조가 어떻고, 외부/내부 이벤트에 어떻게 반응할 지를 나타냅니다. 이후 특정 플랫폼에 맞게 세부사항을 변경하는 PSM의 기반이 됩니다.
PSM은 특정 플랫폼에서 시스템이 어떻게 동작할지를 모델링하는 것입니다. 각각의 적용되는 플랫폼에 따라 PIM을 변형해서 만듭니다. 플랫폼과 관련된 세부사항들을 포함하며 PSM이 실제 코드로 변환되기 때문에 최종적인 구현에 가장 가까운 모델입니다.
+ Excutable code에서 verification을 할 필요는 없다. specification에 따라서 CIM을 만들고, Translator 자체적으로 검사를 하기 때문이다
+ PIM에서 PSM으로 넘어가는 단계를 보여준다
Adoption of MDA
Limitations on adopting MDE/MDA
- Specialized tool support is required to convert models from one level to another
- There is limited tool availability and organizations may required tool adaptation and customization to their environment
- It can be cheaper to programming than modeling
MDE/MDA를 하기 위해서는 특수한 도구가 지원되야합니다. 또한 그 도구를 사용하는 환경에 맞춰서 그것을 적응시키고 개인화하는 것이 필요하다는 단점도 존재합니다. 마지막으로 그냥 프로그래밍하는 것이 모델링 하는것보다 더 효율적일 수도 있습니다.
Models are a good way of facilitating discussion about a software design
- However, the abstractions that are useful for discussions may not be the right abstractions for implementation
- For most complex systems, implementation is not the major problem - requirements engineering, security and dependability, integration with lagecy systems and testing are all more significant
모델은 소프트웨어 디자인에 대해 건설적인 회의를 하기 위한 좋은 방법이긴 합니다. 하지만 그 추상화된 모델이 구현을 위한 올바른 추상화 모델이 아닐 수도 있습니다. 또한 대부분의 복잡한 시스템에서는 구현이 그렇게 큰 문제는 아닙니다. 요구공학, 의존성이나 안전성, 기존 시스템과의 통합 등이 더 중요합니다.
The arguments for platform-independence are only valid for large, long-lifetime systems
- For most software products and information systems, the saving from the use of MDA are likely to be outweighted by the costs of its introducing and tooling
PIM같은 플랫폼 독립적인 모델은 오직 크고, 생명주기가 긴 시스템에 한해서만 유효합니다. 앞서 말했듯, 시스템의 크기가 크지 않다면 오히려 손해일 수 있습니다.
MDE Example: SCADE
+ MDE는 앞서 말한 이유들 때문에 여러 분야에서 사용되기 보다는 safty critical한 분야에 한해서 사용된다
SASD (Structured Analysis and Structured Design)
Structured Analysis
Structured Analysis
- A set of technique and graphical tools
- Allowing the analysts to develop a new kind of system specification that are easily understandable to the users
- Data/Functional modeling: DFD, ERD (Entity Relationship Diagram)
- State-oriented modeling: STD (FSM)
구조적 분석은 사용자가 이해하기 쉬운 새로운 시스템의 스펙을 만들기 위한 분석입니다. 이는 Data/Functional modeling에 해당하는 DFD와 ERD가 있으며, State-oriented modeling에 해당하는 STD (FSM)이 있습니다.
Analysts attempt to divide large, complex problems into smaller, more easily handled ones
- Top-Down Divide and Conquer approach
SA - An Example of RVC SW Controller
Statement of Purpose - RVC Example
User Requirements (Business Requirements)
System Context Diagram (External View)
A special case of DFD
- DFD Level 0
- Highlight the boundary between the system and outside world
- Highlight the people, organizations and outside systems that interact with the system under development
SCD는 DFD의 특수 케이스로 DFD level 0입니다.
이는 바깥 세상과 시스템의 경계를 보여주고,
시스템이 상호작용하는 사람, 조직, 다른 시스템을 보여줍니다.
Event List
A list of the event/stimuli outside of the system to which it must respond
- Uesd to describe the context diagram in detail
Types of inputs events
- Flow-oriented event: triggered by incoming data
- Temporal event: triggered by internal clock
- Control event (state change event): triggered by an external unpredictable event
event list는 시스템이 반드시 반응해야하는 외부의 자극 혹은 이벤트의 리스트입니다.
이는 주로 SCD의 디테일로 작성됩니다.
Data Flow Diagram (DFD)
Provides a means for functional dcomposition
- Composed of hierachies(levels) of DFDs
Notation
+ Data Process의 output은 Data Flow만 허용한다. 사실 당연하다 어떤 데이터를 다루는 프로세스의 결과가 state의 변경은 아닐테니까
+ Data Process의 input은 Data/Control Flow 모두 허용한다
+ Control Process의 input과 output모두 Data/Control Flow를 허용한다
DFD Level 0
DFD Level 1
+ DFD가 계층적으로 존재함을 알 수 있다
DFD Level 2
DFD Level 3
DFD Level 4 (with FSM)
'[학교 수업] > [학교 수업] Software Engineering' 카테고리의 다른 글
| [Software Engineering] 11주차 (2) (0) | 2024.11.15 |
|---|---|
| [Software Engineering] 9주차 (1) (4) | 2024.10.28 |
| [Software Engineering] 7주차 (2) (2) | 2024.10.16 |
| [Software Engineering] 7주차 (1) (1) | 2024.10.14 |
| [Software Engineering] 6주차 (1) (1) | 2024.10.07 |
