软件工程(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