发布时间 : 星期二 文章软件工程(9v)(30+10)双语 讲义 大纲模式 - 图文更新完毕开始阅读
completion of cooking, the buzzer is sounded for five seconds. Oven light is on. Display shows ‘Cooking complete’ while buzzer is sounding. Stimulus Half power Full power Timer Number Door open Door closed Start Cancel
Description The user has pressed the half-power button. The user has pressed the full-power button. The user has pressed one of the timer buttons. The user has pressed a numeric key. The oven door switch is not closed. The oven door switch is closed. The user has pressed the Start button. The user has pressed the Cancel button. Microwave oven operation
Page 41 of 91
4.7 Model-driven engineering 4.8 Introduction
1. Model-driven engineering (MDE) is an approach to software development where models
rather than programs are the principal outputs of the development process.
2. The programs that execute on a hardware/software platform are then generated automatically
from the models.
3. Proponents of MDE argue that this raises the level of abstraction in software engineering so
that engineers no longer have to be concerned with programming language details or the specifics of execution platforms.
4.8.1 Usage of model-driven engineering
A.1 Model-driven engineering is still at an early stage of development, and it is
unclear whether or not it will have a significant effect on software engineering practice. B.1 Pros
Allows systems to be considered at higher levels of abstraction
Generating code automatically means that it is cheaper to adapt systems to new platforms.
B.2 Cons
Models for abstraction and not necessarily right for implementation.
Savings from generating code may be outweighed by the costs of developing translators for new platforms.
4.8.2 Executable UML
1. The fundamental notion behind model-driven engineering is that completely automated
transformation of models to code should be possible.
2. This is possible using a subset of UML 2, called Executable UML or xUML.
4.9 Key points
1. A model is an abstract view of a system that ignores system details. Complementary system
models can be developed to show the system’s context, interactions, structure and behavior. 2. Context models show how a system that is being modeled is positioned in an environment
with other systems and processes.
3. Use case diagrams and sequence diagrams are used to describe the interactions between users
and systems in the system being designed. Use cases describe interactions between a system and external actors; sequence diagrams add more information to these by showing interactions between system objects.
4. Structural models show the organization and architecture of a system. Class diagrams are
used to define the static structure of classes in a system and their associations.
5. Behavioral models are used to describe the dynamic behavior of an executing system. This
behavior can be modeled from the perspective of the data processed by the system, or by the
Page 42 of 91
events that stimulate responses from a system.
6. Activity diagrams may be used to model the processing of data, where each activity
represents one process step.
7. State diagrams are used to model a system’s behavior in response to internal or external
events.
8. Model-driven engineering is an approach to software development in which a system is
represented as a set of models that can be automatically transformed to executable code.
4.10 Excercises(Homework): P143-144
5.2，5.5，5.6，5.7
Page 43 of 91
Chapter 5 (6) Architectural Design
5.1
1. 2. 3. 4.
Topics covered
Architectural design decisions Architectural views Architectural patterns Application architectures
5.2 Architecture design
5.2.1 Software architecture design A.1 Software architecture design
? The design process for identifying the sub-systems making up a system and the framework
for sub-system control and communication is architectural design
? The output of this design process is a description of the software architecture
The architecture of a packing robot control system
A.2 Advantages of explicit architecture
B.1 B.2 B.3
Stakeholder communication System analysis Large-scale reuse
Architecture may be used as a focus of discussion by system stakeholders.
Means that analysis of whether the system can meet its non-functional requirements is possible. 1. The architecture may be reusable across a range of systems 2. Product-line architectures may be developed.
Page 44 of 91