Program Design (プログラム設計)

Program Design
(プログラム設計)
Shaoying Liu (劉 少英)
Faculty of Computer and Information
Sciences
Hosei University
Email: [email protected]
URL: http://cis.k.hosei.ac.jp/~sliu/
The goal of this course
(この課程の目標)
What is program design about(プログラム設計とは)
Process of program design(プログラム設計プロセス)
Principles of program design (プログラム設計原理)
Methods for program design(プログラム設計方法)
Representations of program design(プルグラム設計の
表現)
Other related issues in program design(関連する問題)
The way to study this course
(この課程の勉強仕方)
Attend lectures (授業に出席する)
Take the class of Program Design Experiment
(「プログラム設計演習」を取る)
The conditions for getting the credit of
the course Program Design
(プログラム設計の単位をとる条件)
Attend the class (20%)(授業に出席すること。
20%)
Pass the final examination (80%) (最終試験を
合格すること。80%)。
The conditions for getting the credit of the
course Program Design Experiment
(プログラム設計演習の単位を取る条件
Attend the class (20%) (授業に出席すること。
20%)
Do exercises in the class (30%) (授業で練習問題
をする。30%)
Complete a small project (50%) (一つの小さなプ
ロジェクトを完成する。50%)
Reference books
(参考書)
“Software Design”, by David Budgen, Addison-Wesley,
1994. ISBN: 0-201-54403-2.
“プログラム設計”, 林雄二著、森北出版株式会社、19
96年。ISBN: 4-627-82250-2.
“ソフトウェア工学の基礎”、玉井哲雄著、岩波書店、
2004。ISBN:4-00-005608-5.
“構造化分析とシステム仕様”, トム・デマルコ著、
高梨智弘訳、日経BP出版センター、2000年。
ISBN: 4-8227-1004-1.
“Fundamentals of Object-Oriented Design in UML”, by
Larry L. Constantine, Dorset House Publishing and
Addison-Wesley, 2000.
ISBN: 0-201-69946.
The contents of this course
(この授業の内容)
Part I: Overview of program design(プログラム設計に
ついて)
Part II: Structured design methods and
representations(構造化設計と表示)
Part III: Object-Oriented design methods and
UML (Unified Modeling Language)(オブジェク
ト指向設計とUML)
Part IV: Documentation(設計文書)
URL:http://cis.k.hosei.ac.jp/~sliu/
Part I: Overview of program
design
(プログラム設計について)
1. Introduction to program design
プログラム設計の紹介)
What is design(設計とは)
What is a program(プログラムとは)
What is program design(プログラム設計と
は)
Principles of program design(プログラム設
計の原理)
Overview of design methods(設計方法の
紹介)
1.1 What is design
When building any complex products, such as cars,
bridges, houses, computers, airplanes, trains, and
so on, it is always necessary to make a welldocumented plan to tell how to build them, before
they are actually built. The process and activity
for making and documenting such a plan is called
design.
(製品の設計とは、その製品を製造するために必
要な計画又はモデルを作成するプロセスと活動
である)
Example
1. Study user requirements: build a house with the
following parts:
two sides
one end
one door
two roof panels
one front
2. Build an abstract model of the house (abstract
description of the solution)
2 sides
1
door
1 end
2 roof
panels
1 front
3. Evaluate the model against the user requirements.
4. Modify and refine the abstract model to produce
a detailed model of the house.
1 back
1 front
Bedroom3
Living room
toliet
2 ends
2 roof panels
bathroom
Kitchen
Bedroom2
Bedroom1
front door area
User
requirements
Design
Abstract model
User
requirements
Design
Product
Product
Description: design is a process of constructing a
preliminary plan or model for
producing an expected product or
object.
(設計とは、製品を生産するために必要な計画又
はモデルを作成するプロセスと活動である。)
1.2 What is program
Description: a program is an algorithm written in a
programming language that provides
behaviors.
(プログラムとは、一定のプログラミング言語で書
いたある機能を持つアルゴリズムである。)
Program = Algorithm
+
Data structure
Description: an algorithm is a sequence of actions
or commands.
(アルゴリズムとは、操作又は命令の並びである。)
Example: compute the average score of a class
with 40 students.(40人を持つクラスの平均成績
を求める。)
(1) Input all scores of the class(クラス全員の成績の入力)
(2) Compute the total score of the class(成績の合計の計算)
(3) Divide the total score of the class by the
number of students in the class
(合計を学生の人数で割る)
(4) Print out the average score (平均成績のプリント)
A Java-like program for the average score problem:
int number = 0, totalScore = 0;
double averageScore = 0;
//these variables represent date structures
for (int count = 0; count <= 39; count++)
{
number = read a score;
totalScore = totalScore + number;
}
avergeScore = totalScore / 40;
System.out.println(“The average score is:” + averageScore);
Mathematical abstraction of a program: a program
is a function:
(プログラムの意味は数学の関数で表す。)
P: D --> R
where P denotes a program; D is its domain; and
R is its range.(Pはプログラム、Dはドメイン、
Rは値域である)
In fact, the essential task of constructing a program is to
determine the following two elements:(プログラムの作成
は、次のような二つのことが決まることである)
(1) domain and range(ドメインの決まり)
(2) definition of the function P(関数Pの定義又は表現)
1.3 What is program design
Description: program design is a process of
constructing a preliminary plan or
model for producing an expected
program.
(プログラム設計とは、期待されたプログラムを作
成するために必要な計画又はモデルを作成する
プロセスである)
When is program design carried out in
the software development process?
(設計はいつ行われるのか。)
Requirements specification
Abstract design
Program design
Detailed design
Coding
Abstract design: it covers the following activities:
Identify necessary components, including data items
and operations. This may include definitions of the
data items and the functionalities of the operations.
(データと操作の発見及び定義)
Determine the architecture (or structure) of the
program that indicates the way to integrate the
operations at an abstract level.(プログラムの構造の
描画)
Determine relations between data items and
operations. For example, what operation processes
what data items.(データと操作の間の関係の定義)
Detailed design: it covers the following activities:
Define concrete data structures for all the data items
identified in the abstract design. Usually, these data
items are defined using the data structures available in
a specific programming language (e.g., Java, C).(デー
タ項目のデータ構造が決まる)
Define the functionality of the operations identified in
the abstract design in detail.(操作の機能を定義する)
Determine algorithms for implementing the
operations.(操作の機能を実装するアルゴリズムが
決まる)
Establish precise logical relations between operations.
For example, under what conditions which operations
can be integrated to provide what behavior.(関連する
操作の論理的な関係が決まる)。
Characteristics of program design
(プログラム設計の特徴)
The process of program design lacks a definitive formula to follow.
In other words, there is no absolute rule for design. This is different
from solving a mathematical problem. (プログラム設計には、確
定的な数式がない)
There is a lack of quality measures that can be used to establish
that any program design is the ‘best’ one possible.(プログラムが最
高かどうかを評価する基準がない)
There is no true or false program design, but good or bad.(真の設
計か偽の設計かを決められない。良い設計か良くない設計かを
決められる)
Program design is a process of creating problems and resolving
problems.(プログラム設計は、問題を作りながらそれらの問題を
解決するプロセスである)
Program design is an intellectually rigorous discipline. (プログラ
ム設計は、知的、厳密的な作業である)
Questions to think about
What is the goal of program design?
What is a program?
Can you give an example that describes the
process of designing and implementing a product?
What is the relationship between a design and a
program? Should the design documentation be
part of the program?
1.4 Program qualities achievable by
design
(設計で獲得できるプログラムの品質)
Reliability – a measure of continuous delivery of
proper service. It reflects the degree to which a
program satisfies its requirements that specifies
the proper services. For example, a car, TV set,
computer.(信頼性ー適当なサービス を連続的
に提供する程度)
Correctness – a property that a program satisfies its functional
specification for any input in its domain.(正確性ープログラムが
機能仕様を満たすかどうかの性質)
Since there is usually a gap between real requirements and the
specification that is supposed to document the requirements, a
program is correct does not necessarily mean it is 100% reliable.
Efficiency – a measure of the running speed of a
program and the consumption of memory during
operations.(効率ープログラムの実行速度と使ったメモリ量のこ
と)
Usability – a measure of how easily a program can be used in its
operation. (有用性ープログラムがどのような簡単に使われるこ
と)
Maintainability – a measure of how easily a program can be
modified or extended after it is delivered for operation. (保守性ー
プログラムをどのように簡単に修正又は拡大すること)
Readability – a measure of how easily a program can be
read and understood. (読みやすさ又は可読性ープログ
ラムはどのような簡単に読み、理解できること)
Reusability – a measure of how easily a program or its
components can be reused for building different parts of
the same program or other programs. (再利用性ープロ
グラム又はプログラム部品はどのような簡単に他のプ
ログラム又は部品に利用されること)
• Robustness – a measure of a program’s ability to recover
gracefully whenever a failure occurs. (Typical failures are
memory violations, external device errors, and arithmetic
overflows). For example, exception handling in Java is a
mechanism to enhance the robustness of programs.(健壮
性ープログラムは失敗から順調 に回復する能力)
Classification of the qualities
(プログラム品質の分類)
Reliability, correctness, efficiency, and usability
are the qualities that are great concern of the
users.(ユーザの関心が高い性質)
Maintainability, readability, reusability, and
robustness are the qualities that are great concern
of the program developers.(プログラムの開発者
の関心が高い性質)
How to achieve program qualities by
program design
(プログラムの品質は設計でどのように得
られるのか)
Design programs with good principles. (良い原理でプロ
グラムを設計すること)
Design programs with effective methods. For example,
top-down, bottom-up, modular, structured, and objectoriented designs (which will be explained later). (有効な
設計方法を使うこと)
Design programs with comprehensible notations. For
example, graphical notations, structured English.(理解し
やしい言語又は表記法でプログラムの設計を表すこ
と)
1.5 Principles of program design
(プログラム設計の原理)
Abstraction and decomposition.(抽象と分解)
Abstraction is a way to express the most important
information of the program without telling its
implementation details. (抽象は具体的な情報を含ま
ない最も重要な情報を表す手法である)
Decomposition is a way to divide a big task into small
tasks, and to develop details of an abstraction. The
benefit of decomposition is to reduce the complexity of
programs. (分解は大きなタスクを小さなタスクに割り、
抽象したものを詳細する手法である)
For example, description of Hosei University:
(例えば、法政大学の描画)
Abstraction: Hosei University has three campus:
Ichigaya, Koganei, and Tama campuses.
(抽象:法政大学は、市ヶ谷、小金井、及び多摩と
いう三つのキャンパスを持つ大学である。)
Decomposition: Ichigaya campus has faculties of
Business Administration, Law, Letters,
Intercultural Communication, Humanity and
Environment. Koganei campus has faculties of
Engineering, and Computer and Information
Sciences. Tama campus has faculties of
Economics, Social Sciences, and Social Policy
and Management.
(分解:市ヶ谷キャンパスでは、経営学部、法学部、
文学部、国際文化学部、人間環境学部がある。
小金井キャンパスでは、工学部と情報科学部が
ある。多摩キャンパスでは、経済学部、社会学部、
及び現代福祉学部)
Encapsulation(カプセル化 )
Encapsulation is the grouping of related ideas into one
unit, which can thereafter be referred to by a single name.
(カプセル化は、関連するプログラム部品(データ、操
作)を一つのプログラム単位に入れる)
For example,
class Stack
int[] a = new int[10];
int top = 0;
Initialize;
Push;
Pop
a
top
Empty stack
top
a
x
y
z
Stack after pushing
x, y, and z
top
a
x
y
Stack after popping up z
Information hiding(情報隠蔽)
Information hiding is the use of encapsulation to restrict from
external visibility certain information or implementation decisions
that are internal to the encapsulation structure. (情報隠蔽とは、カ
プセル化という仕組みにより必要なデータ情報又は操作の実装
情報を制限する)
For example,
class Stack
private int a[] = new a[10];
private int top = 0;
public Initialize;
public Push;
public Pop;
public Other necessary operations;
Modularity(モジュール化)
Modularity is a property that a program consists of
many independent modules. A module is a
modest-sized component that performs
independently specific functions. (モジュール化
は、プログラムを規模が小さい多数のモジュー
ルから構成させる)
For example, computers, cars, Japanese food.
To support these principles, many design methods
have been developed, which are introduced next.
Questions to think about
Let us take car as a product. Explain the following
qualities of the car, with examples.
• Reliability
• Correctness
• Efficiency
• Usability
• Maintainability
• Extendability
• Reusability
• Robustness
1.6 Overview of Design methods
(設計方法の紹介)
Top-down design(トップ ーダウン設計)
Bottom-up design(ボトム ーアプ設計)
Modular design(モジュール式の設計)
Structured design(構造化設計)
Object-Oriented design(オブジェクト指向設
計)
Component-based design(分品に基づく設計)
1.6.1 Top-down design
(トップ ーダウン設計)
Top-down design supports the “abstract and
decomposition” principle. By this design method, a
system is first abstracted as a high level unit (e.g.,
module, process, procedure, function), and then
decomposed into low level units, possibly integrated
together using some constructs. Usually such a
decomposition process focuses on either data flow or
control flow of the program.
(トップ ーダウン設計は、抽象と分解という設計原理を支
える)
For example, a “University Information System” is
designed using top-down method as follows:
(大学情報システムをトップ ーダウンで設計する)
Top level:
University
Information System
Decomposition:
University
Information System
Course management
Research
management
Decomposition:
University
Information System
Research
management
Course management
Lecture management
Examination
management
Study records
management
Decomposition:
University
Information System
Research
management
Course management
Lecture management
Examination
management
Projects
management
Study records
management
Publications
management
Reserach-related
events management
(e.g., conferences)
1.6.2. Bottom-up design
(ボトム ーアプ設計)
Bottom-up design takes the opposite approach to top-down
design:
(1) First investigate the most important and crucial but low
level functions or modules of a program system.(まず
低いレベルの重要なモジュールを設計する)
(2) Then integrate those low level modules into high level
modules that is closer in meeting the requirements.(低
いレベルのモジュールを統合して高いレベルのモ
ジュールを構成する)
(3) Integrated modules are also treated as well-designed low
level modules in the integration process.(構成されたモ
ジュールも他のモジュールを構成するために使われら
れるモジュールとなる)
For example, we start the design with investigating
the following low level functions.
Lecture management
Examination
management
Study records
management
Then the following functions:
Projects
management
Publications
management
Reserach-related
events management
(e.g., conferences)
Then we integrate those low level functions to
construct more powerful functions:
Research
management
Course management
Lecture management
Examination
management
Projects
management
Study records
management
Publications
management
Reserach-related
events management
(e.g., conferences)
Finally, we build the entire design to meet the
requirement:
University
Information System
Research
management
Course management
Lecture management
Examination
management
Projects
management
Study records
management
Publications
management
Reserach-related
events management
(e.g., conferences)
The comparison between top-down and bottom-up
design methods:(トップ ーダウン設計とボトム ー
アプ設計の比較)
Top-down design is a process of development
from abstract ideas to concrete ideas.(トップ-ダ
ウン設計は、抽象表現から詳細表現へ発展する
プロセスである)
Bottom-up design is a process of development
from concrete ideas to abstract ideas, representing
a synthesis (綜合).(ボトム ーアプ設計は、具体的
な表現から抽象表現へ発展するプロセスである)
Top-down is more suitable for designing program
systems that is not familiar to the designer, whereas
bottom-up approach is more suitable for designing
familiar program systems. Using what design method
should depend on how much you are familiar with the
domain.(トップ-ダウン設計は、新しいシステムの開発
に有効である。ボトム ーアプ設計は、既に良くしている
ドメイン の新しいシステムの開発に有効である。
Top-down design supports “goal-oriented” approach in a natural
manner, therefore, has less risk in designing an unsatisfactory
program, whereas bottom-up design is opposite to the goaloriented approach, therefore, has more risk in designing an
unsatisfactory program.(トップ-ダウン設計では、ゴール
指向設計を支えるから、満足でないシステムを作成す
るリスクが少ない。ボトム ーアプ設計では、そのリスク
が相対的に大きい。
1.6.3 Modular design
(モジュール式の設計)
Modular design is way of designing a program as a set of
related modules. (モジュール式の設計は、いくつかの
モジュールを設計することによりプログラム全体を設計
する手法である)
A module is a modest-sized subprogram that performs
independently one specific function. (モジュールは、
一つの機能を実装する普通の規模のプログラム単位)
The emphasis of modular design is on the concept: a set of
modules, not on the way to achieve it. One can build
such a set of modules either using top-down or bottomup method.
The characteristics of a module:(モジュールの特徴)
modest-size.(普通の規模)
Independent performance of a specific function.(一つの
独立な機能を持つ)
Encapsulation of data and operations.(データと操作のカ
プセルにする)
Implementation hiding.(実装の詳細情報を隠蔽する)
Replaceable. That is, if we substitute a new module of
different design for an old one and maintain the same
function (or behavior), the entire program system should
work well with little or no change. (置き換えられる)
For example, a car is composed of many components,
including engine, car body, wheels, battery, and so on.
1.6.4 Structured design
(構造化設計)
Structured design is a way to achieve programs that are
composed of only single-entry and single-exit control
constructs in a hierarchical fashion. A program satisfying
such a property is called structured program.(構造化設
計とは、階層的な構造で、「一つの入口と一つの出口」
を持つプログラムを設計する手法である)
A structured program offers the following advantages:
Easy to read and understand.(プログラムは読みやすい)
Easy to test and debug.(テスト及びデイバグしやすい)
Easy to prove the correctness.(プログラムの正確性の証
明が容易である)
In general, there are three kinds of single entry and
single exit constructs: sequence, choice (or
selection), and iteration. These three constructs
are usually expressed using the following three
statements in a programming language:(「一つの
入口と一つの出口」を持つプログラム構造が次
の三つである)
S1; S2
if C then S1 else S2 (or if (C) S1 else S2)
while C do S (or while (C) S)
The flowcharts of these constructs are:
yes
task1
task2
Sequence
no
yes
C
C
task1
task2
Choice
no
task1
Iteration
The hierarchical structure of a program is created
when calling subprograms (or modules,
procedures (Pascal), functions (C), methods
(Java)). (プログラムの階層的な構造は、モ
ジュールの呼び出しにより、 「一つの入口と一つ
の出口」の性質を維持しながら形成された)
The characteristics of such a hierarchical structure
is to keep the property of single-entry and singleexit.
Subprogram1
calling point;
return point;
Subprogram2
calling point;
return point;
Subprogram3
calling point;
return point;
Subprogram10
calling point;
return point;
Although structured design is not necessarily
carried out in top-down and modular manner,
experience in practice shows that top-down and
modular manner is the most effective way to
achieve good quality structured programs.
Therefore, structured design is usually interpreted
as the combination of top-down and modular
design that achieves single-entry and single-exit
programs.
Structured design = Top-down
+
Modular
+
Hierarchical
design
(構造化設計=トップ-ダウン +
モジュール式 +
階層的な設計)
1.6.5 Object-oriented design
(オブジェクト指向設計)
Object-oriented design is a way of designing a program system by
focusing on the design of objects and their integration. (オブジェ
クト指向設計とは、オブジェクト及びオブジェクトの間の関係を重
視しながらプログラムを設計する手法である)
An object is an encapsulation of attributes and operations (or
methods); it takes inputs and performs some functions. In fact, an
object is a kind of module.(オブジェクトは、属性(データ)と操作
をかぶせる化したものである)
An object-oriented program can be regarded as a network of objects
that interact with each other by means of sending and receiving
messages (which are similar to calling methods in Java).
Obj1
Obj6
Obj2
Obj0
Obj5
Obj3
Obj4
1.6.6 Component-based design
(部品に基づく設計)
Component-based design is an approach to designing a
program using well-constructed software components
that are available for use.(部品に基づく設計は、既に構
築されてあるプログラム部品(モジュール)を用いてプ
ログラムを作成する手法である)
Abstractly, a component is like a module, which performs a
specific function under a certain condition. It is a basic
block for building programs. Of course, a component can
be either simple or complex, either small or large.
Specifically, a component can be a function, object, or their
integration. There is no agreed, unique, and formal
definition of component.
In fact, component-based design is a specialization of
modular design method, with the following
characteristics: (部品に基づく設計は、モジュール式の
設計の一つである)(プログラム部品が次の特徴を持つ
はずである)
Components are well-constructed and ready to use.(部品
は、既に使われられる状態である)
Components’ interfaces and functions are well-defined.
(部品のインタフェースと機能が良く定義されている)
Components can be plug in to program systems easily.
(部品は、プログラムに簡単に投入できる)
Components are usually language-specific.(部品は、一
般てきに言語特定である)
(for example, Java AWT and SWING offer powerful
components for building Java programs).
Exercise 1
(1) Give an example to explain the following
concepts(事例を用いて、次の概念を説明しなさ
い)
Reliability
Correctness
Efficiency
Usability
Maintainability
Reusability
Robustness
(2) Give an example to explain the following design
methods(事例を用いて次の設計方法を説明しな
さい)
Top-down design
Bottom-up design
Modular design
Component-based design
Object-Orient design