1 / 66

Program Design ( プログラム設計)

Program Design ( プログラム設計). Shaoying Liu ( 劉 少英) Faculty of Computer and Information Sciences Hosei University Email: sliu@k.hosei.ac.jp URL: http://cis.k.hosei.ac.jp/~sliu/. The goal of this course (この課程の目標). What is program design about (プログラム設計とは) Process of program design (プログラム設計プロセス)

Download Presentation

Program Design ( プログラム設計)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Program Design (プログラム設計) Shaoying Liu (劉 少英) Faculty of Computer and Information Sciences Hosei University Email: sliu@k.hosei.ac.jp URL: http://cis.k.hosei.ac.jp/~sliu/

  2. 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(関連する問題)

  3. The way to study this course(この課程の勉強仕方) • Attend lectures (授業に出席する) • Take the class of Program Design Experiment(「プログラム設計演習」を取る)

  4. The conditions for getting the credit of the course Program Design(プログラム設計の単位をとる条件) • Attend the class (20%)(授業に出席すること。20%) • Pass the final examination (80%) (最終試験を合格すること。80%)。

  5. 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%)

  6. Reference books(参考書) • “Software Design”, by David Budgen, Addison-Wesley, 1994. ISBN: 0-201-54403-2. • “プログラム設計”, 林雄二著、森北出版株式会社、1996年。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.

  7. 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/

  8. Part I: Overview of program design(プログラム設計について)

  9. Introduction to program designプログラム設計の紹介) • What is design(設計とは) • What is a program(プログラムとは) • What is program design(プログラム設計とは) • Principles of program design(プログラム設計の原理) • Overview of design methods(設計方法の紹介)

  10. 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 well-documented 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. (製品の設計とは、その製品を製造するために必要な計画又はモデルを作成するプロセスと活動である)

  11. Example 1. Study user requirements: build a house with the following parts: • two sides • one end • one door • two roof panels • one front

  12. 2. Build an abstract model of the house (abstract description of the solution)

  13. 3. Evaluate the model against the user requirements. 4. Modify and refine the abstract model to produce a detailed model of the house.

  14. Description:design is a process of constructing a preliminary plan or model for producing an expected product or object. (設計とは、製品を生産するために必要な計画又はモデルを作成するプロセスと活動である。)

  15. 1.2 What is program Description: a program is an algorithm written in a programming language that provides behaviors. (プログラムとは、一定のプログラミング言語で書いたある機能を持つアルゴリズムである。)

  16. 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 (平均成績のプリント)

  17. 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);

  18. 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の定義又は表現)

  19. 1.3 What is program design Description:program design is a process of constructing a preliminary plan or model for producing an expected program. (プログラム設計とは、期待されたプログラムを作成するために必要な計画又はモデルを作成するプロセスである)

  20. When is program design carried out in the software development process?(設計はいつ行われるのか。)

  21. 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.(データと操作の間の関係の定義)

  22. 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 conditionswhich operations can be integrated to provide what behavior.(関連する操作の論理的な関係が決まる)。

  23. 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. (プログラム設計は、知的、厳密的な作業である)

  24. 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?

  25. 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.(信頼性ー適当なサービス を連続的に提供する程度)

  26. 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. (保守性ープログラムをどのように簡単に修正又は拡大すること)

  27. 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.(健壮性ープログラムは失敗から順調 に回復する能力)

  28. 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.(プログラムの開発者の関心が高い性質)

  29. 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 object-oriented designs (which will be explained later). (有効な設計方法を使うこと) • Design programs with comprehensible notations. For example, graphical notations, structured English.(理解しやしい言語又は表記法でプログラムの設計を表すこと)

  30. 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. (分解は大きなタスクを小さなタスクに割り、抽象したものを詳細する手法である)

  31. For example, description of Hosei University: (例えば、法政大学の描画) Abstraction: Hosei University has three campus: Ichigaya, Koganei, and Tama campuses. (抽象:法政大学は、市ヶ谷、小金井、及び多摩という三つのキャンパスを持つ大学である。)

  32. Decomposition: Ichigaya campus has faculties of Business Administration, Law, Letters, Intercultural Communication, Humanityand 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. (分解:市ヶ谷キャンパスでは、経営学部、法学部、文学部、国際文化学部、人間環境学部がある。小金井キャンパスでは、工学部と情報科学部がある。多摩キャンパスでは、経済学部、社会学部、及び現代福祉学部)

  33. 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

  34. 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;

  35. 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.

  36. 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

  37. 1.6 Overview of Design methods(設計方法の紹介) • Top-down design(トップ ーダウン設計) • Bottom-up design(ボトム ーアプ設計) • Modular design(モジュール式の設計) • Structured design(構造化設計) • Object-Oriented design(オブジェクト指向設計) • Component-based design(分品に基づく設計)

  38. 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. (トップ ーダウン設計は、抽象と分解という設計原理を支 える)

  39. For example, a “University Information System” is designed using top-down method as follows: (大学情報システムをトップ ーダウンで設計する) Top level:

  40. Decomposition:

  41. Decomposition:

  42. Decomposition:

  43. 1.6.2. Bottom-up design(ボトム ーアプ設計) Bottom-up design takes the opposite approach to top-down design: • 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.(構成されたモジュールも他のモジュールを構成するために使われられるモジュールとなる)

  44. For example, we start the design with investigating the following low level functions.

  45. Then the following functions:

  46. Then we integrate those low level functions to construct more powerful functions:

  47. Finally, we build the entire design to meet the requirement:

  48. 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 (綜合).(ボトム ーアプ設計は、具体的な表現から抽象表現へ発展するプロセスである)

More Related