13. Development methods

Today's topics

History of software engineering

Extreme programming (XP)

Software engineering research

50 years of history

Techniques for creating reliable software

Articles on software engineering

IPSJ magazine (2017)

https://ipsj.ixsq.nii.ac.jp/ej/index.php?action=pages_view_main&active_action=repository_view_main_item_snippet&index_id=8967&pn=1&count=20&order=7&lang=japanese&page_id=13&block_id=8 https://gyazo.com/c7faba8c4cf69d6e7d5ccf542283caa9

by Tetsuo Tamai (2008)

https://gyazo.com/5a2f2e58c8316597c85f0758666e4521

Techniques

New programming languages

Structured progrmming

No GOTOs

Object-oriented programming

Testing methods

Formal specification

Visual specification

UML (Unified Modeling Language)

CMM

Criticism on GOTO statement

Proposed 'structured programing'

Structured programming

Restrict program structure

while, if, etc.

GOTO considered harmful

Object-oriented programming

Object-oriented languages

Simula (1967)

Smalltalk (1980)

C++ (1983)

Objective-C (1983)

OOPSLA (Object-Oriented Programming, Systems, Languages, and Applications) conference

1986-2008

Waterfall model

https://gyazo.com/541a7f4ee035d92da3887872b2302b16

Waterfall model

Waterfall model

Planning phase is important

Development after complete design & planning

Formal specification

from Wikipedia

In computer science, formal specifications are mathematically based techniques whose purpose are to help with the implementation of systems and software. They are used to describe a system, to analyze its behavior, and to aid in its design by verifying key properties of interest through rigorous and effective reasoning tools. These specifications are formal in the sense that they have a syntax, their semantics fall within one domain, and they are able to be used to infer useful information.

from Z manual

Formal specifications use mathematical notation to describe in a precise way the properties which an information system must have, without unduly constraining the way in which these properties are achieved. They describe what the system must do without saying how it is to be done. This abstraction makes formal specifications useful in the process of developing a computer system, because they allow questions about what the system does to be answered confidently, without the need to disentangle the information from a mass of detailed program code, or to speculate about the meaning of phrases in an imprecisely-worded prose description.

Formal specification languages

LOTOS

Z specification example

https://gyazo.com/579e864894c7640884f4c4466b861396

Specification and code

Specification

https://gyazo.com/a53c6edba027b9f6df3f17bcec0409f4

Pascal code

https://gyazo.com/aa67599dbb85272c869f47d19e5f82a9

Problems of formal specification

Writing specifications is as difficult as writing codes

Difficult to understand the concept

Modern practices

Agile development

Extreme programming

Test-driven develpment (TDD)

Continuous integration (CI)

Agile development

https://gyazo.com/2676785fe25d703199c84155deac0325

c.f. Waterfall model

https://gyazo.com/541a7f4ee035d92da3887872b2302b16

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

4. Business people and developers must work together daily throughout the project.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity--the art of maximizing the amount of work not done--is essential.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

https://gyazo.com/cf38a9e5cca6bbba9829e4d2616e77ef

https://gyazo.com/3daab8caa03cd020ebba05265679d7b0

Make People Awesome

Make Safety a Prerequisite

Experiment & Learn Rapidly

Deliver Value Continuously

https://gyazo.com/435cced9437c136cf76bf3b0eb42c3c2

Proposed by Kent Beck

Practical programming method

Kent Beck

Object-oriented programming professional

Author of Smalltalk books

http://gyazo.com/90e878e7e3991568c575010daaa2c06a.png

Basics

Communication

Simplicity

Feedback

Courage

http://gyazo.com/fa758d64d0dca5d8c0f8bcc1813b5c41.png

XP practices

Repetitive development

Design / implementation / test for each iteration

Release partially-completed producdt

Unit-based implementation

Repetition of code modification and testing

XP practices (Cont'd)

Use common words

Open development space

Easy conversation

Development practice

Test-driven development

Pair programming

Refactoring

Source code sharing

Continuous integration tests

YAGNI

Test-driven development

Write test codes before writing codes

Goal is to write codes which satisfy the tests

Clear goal and simple implementation

Pair programming

https://gyazo.com/735c1c0f9df0486fc392e9d22a0089a3.png

Two person share a terminal and write code

One writes the code

The other check the coding and navigate

Roles changes

Always codes are checked

Keep concenterated

Good for code sharing

Refactoring

Modify working codes

Change codes without changing specs

Strict test environment necessary

Sharing codes

Anyone in the team can modify codes

Everyone is responsible for the codes

1. Maintain a code repository

2. Automate the build

3. Make the build self-testing

4. Everyone commits to the baseline every day

5. Every commit (to baseline) should be built

6. Keep the build fast

7. Test in a clone of the production environment

8. Make it easy to get the latest deliverables

9. Everyone can see the results of the latest build

10. Automate deployment

Continuous integration (CI)

Always run integration tests after unit tests

Integration test at least onece a day

CI tools

https://gyazo.com/45e242791b7752b745a7ae53f265acd4

https://gyazo.com/2e071a06a2e5e358d57d863db2463b8c

https://gyazo.com/f3bcedf8a3fd9165a1152e42ee1c4e27

YAGNI

Implement the minimal code

Don't implement features for the future

Implement only necessary codes

Easy to adapt to future spec changes

Programmers and XP

Many programmers liked the idea

Source codes are more important than documents

Small improvements more important than long-term visions

Program testing

http://gyazo.com/5e7a7dba9271d9217245911b716ceb45.png

Test-first programming

Write test codes at the beginning

Write codes after writing test codes

Go to next step if test was okay

Test-Driven Development (TDD)

Test-Driven Development

1. Write test codes before production

2. Write codes which satisfy test conditions

3. Modify codes and repet checking (Refactoring)

4. GOTO 1

Caveats

Programmers may write insufficient tests

Testers and programmers should be different

Test systems

Unit test frameworks

SUnit (Smalltalk)

JUnit (Java)

RubyUnit (Ruby)

RubyUnit

Test system for Ruby

Use assertions

Initial operations

Termination operations

RubyUnit example

code:test.rb

require 'test/unit'

class ArrayTest < Test::Unit::TestCase

def setup

@empty_array = []

end

def test_empty?

assert(@empty_array.empty?)

end

def test_size

assert_equal(0, @empty_array.size)

end

def teardown

@empty_array = nil

end

end

RSpec example

code:rspec.rb

describe Array, "when empty" do

before do

@empty_array = []

end

it "should be empty" do

@empty_array.should be_empty

end

it "should size 0" do

@empty_array.size.should == 0

end

after do

@empty_array = nil

end

end

JUnit example

code:junit.java

import static org.junit.Assert.*;

import org.junit.Test;

import static org.hamcrest.MatcherAssert.assertThat;

import static org.hamcrest.Matchers.*;

import com.pitecan.gyaim.GoogleIME;

import com.pitecan.gyaim.Message;

public class GoogleIMETest {

String 変換例リスト[][] = {

{"べんきょう", "勉強"},

{"ますい", "増井"},

{"いちのもと", "櫟本"},

{"むさしぼうべんけい","武蔵坊弁慶"},

{"かまくらのかいがん", "鎌倉の海岸"}

};

@Test

public void Google変換チェック() {

for (String[] 変換例: 変換例リスト) {

boolean found = false;

}

assertTrue(found);

}

}

}

Demo: Running tests for Gyaim

Pair programming

https://gyazo.com/5677f1833a2fd64a946186703fd7eebb

Two programmers use one computer

Develop a software together

Complementary roles

e.g. writing test codes and implementation

Advantages

Difficult to be idle

Higher quality expected than single person

Work flow change

Not worry about what to do next

Become tolerant to noises

Changing roles => changing thinking patterns

Advantages (Cont'd)

Some people like working together

Sharing codes

Education effect

Knowledges easily share bay the team

Teamwork

Less interruption

Difficult to interrupt two working person

Less number of computers

Results

Accuracy imprved 15%

Speed improved 20-40%

Total improvement 15-60%

...

Problems

Boring for experienced programmers

Some people hate working together

Efficiency not always improved

Talent unbalance

Coding style conflict

Scheduling

Remote working impossible

Problems

Difficult to have rests

Get tired

Refactoring

Changing codes with same spec

No rigid definition

Refactoring techniques

Extract methods and reuse

Change bidirectional relations to unidirectional

Create small classes

Change switch statement to polymorphism

Clean up class members

Refactoring techniques

Replace subclass with delegation

Encapsulate Downcast

Convert constructors to factory methods

Use objects for arguments

Change names and attributes

70 refactoring methods

https://www.amazon.co.jp/dp/0201485672 https://gyazo.com/5a56a12733942b733acda642573248b0

Test should be complete

Changing code is okay as long as testing done

Design pattern

Catalog of software know-how

"Gang of Four" book

23 patterns listed

http://gyazo.com/c1541545f2bb32608bc10b048075f8c1.png

Patterns on generation

Abstract Factory pattern

Provide an interface for creating families of related or dependent objects without specifying their concrete classes.

関連する一連のインスタンスを状況に応じて適切に生成する方法を提供

Builder pattern

Separate the construction of a complex object from its representation, allowing the same construction process to create various representations.

複合化されたインスタンスの生成過程を隠蔽

Factory Method pattern

Define an interface for creating a single object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.

実際に生成されるインスタンスに依存しない、インスタンスの生成方法を提供

Prototype pattern

Specify the kinds of objects to create using a prototypical instance, and create new objects from the 'skeleton' of an existing object, thus boosting performance and keeping memory footprints to a minimum.

同様のインスタンスを生成するために、原型のインスタンスを複製

Singleton pattern

Ensure a class has only one instance, and provide a global point of access to it.

あるクラスについて、インスタンスが単一であることを保証

Patterns on structure

Adapter pattern

Convert the interface of a class into another interface clients expect. An adapter lets classes work together that could not otherwise because of incompatible interfaces. The enterprise integration pattern equivalent is the translator.

元々関連性のない2つのクラスを接続するクラスを作る

Bridge pattern

Decouple an abstraction from its implementation allowing the two to vary independently.

クラスなどの実装と、呼出し側の間の橋渡しをするクラスを用意し、実装を隠蔽

Composite pattern

Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.

再帰的な構造を表現

Decorator pattern

Attach additional responsibilities to an object dynamically keeping the same interface. Decorators provide a flexible alternative to subclassing for extending functionality.

あるインスタンスに対し、動的に付加機能を追加する。Filterとも呼ばれる。

Facade pattern

Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.

複数のサブシステムの窓口となる共通のインタフェースを提供

Flyweight pattern

Use sharing to support large numbers of similar objects efficiently.

多数のインスタンスを共有し、インスタンスの構築のための負荷を減らす

Proxy pattern

Provide a surrogate or placeholder for another object to control access to it.

共通のインタフェースをもつインスタンスを内包し、利用者からのアクセスを代理する。Wrapperとも呼ばれる。

Patterns on behavior

Chain of Responsibility pattern

Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it.

イベントの送受信を行う複数のオブジェクトを鎖状につなぎ、それらの間をイベントが渡されてゆくようにする。

Command pattern

Encapsulate a request as an object, thereby allowing for the parameterization of clients with different requests, and the queuing or logging of requests. It also allows for the support of undoable operations.

複数の異なる操作について、それぞれに対応するオブジェクトを用意し、オブジェクトを切り替えることで操作の切替えを実現する。

Interpreter pattern

Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language.

構文解析のために、文法規則を反映するクラス構造を作る。

Iterator pattern

Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.

複数の要素を内包するオブジェクトのすべての要素に順にアクセスする方法を提供する。反復子。

Mediator pattern

Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it allows their interaction to vary independently.

オブジェクト間の相互作用を仲介するオブジェクトを定義し、オブジェクト間の結合度を低くする。

Memento pattern

Without violating encapsulation, capture and externalize an object's internal state allowing the object to be restored to this state later.

データ構造に対する一連の操作のそれぞれを記録しておき、以前の状態の復帰または操作の再現が行えるようにする。

Observer pattern

Define a one-to-many dependency between objects where a state change in one object results in all its dependents being notified and updated automatically.

インスタンスの変化を他のインスタンスから監視できるようにする。Listenerとも呼ばれる。

State pattern

Allow an object to alter its behavior when its internal state changes. The object will appear to change its class.

オブジェクトの状態を変化させることで、処理内容を変えられるようにする。

Strategy pattern

Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.

データ構造に対して適用する一連のアルゴリズムをカプセル化し、アルゴリズムの切替えを容易にする。

Template Method pattern

Define the skeleton of an algorithm in an operation, deferring some steps to subclasses. Template method lets subclasses redefine certain steps of an algorithm without changing the algorithm's structure.

あるアルゴリズムの途中経過で必要な処理を抽象メソッドに委ね、その実装を変えることで処理が変えられるようにする。

Visitor pattern

Represent an operation to be performed on the elements of an object structure. Visitor lets a new operation be defined without changing the classes of the elements on which it operates.

データ構造を保持するクラスと、それに対して処理を行うクラスを分離する。

XP and pattern language

Close relationship

Kent Beck invented XP and pattern language

Christopher Alexander

Invented "Pattern Language"

http://gyazo.com/835dfec1ee8d66545ff1cd4933cfe488.png

Ward Canninghum

Invented Wiki Wiki Web

Applied pattern language to software

http://gyazo.com/266865260d7551358e88687c2b6e03be.png

History of object-oriented programming

Simula

Smalltalk

C with classes

C++

Objective-C

Modula2

Eiffel

History of objected-oriented programing

Popular since 1980s

Common knowledge these days

Simula

Simulation language

Information hiding

Smalltalk

Developed at PARC

Integration with GUI

ALTO = GUI + OO + network

C++

"C with classes"

Was a front-end processor for C

Very popular

Objective-C

Developed by Brad Cox

http://www.amazon.com/dp/0201548348/ http://gyazo.com/f1929fecb1b6ec2f3e36a10633cbda1c.png

Objective-C

Smalltalk-like extention of C

Used for NeXT workstation

Used for Apple products

Modula2

Developed by DEC

Eiffel

Bertrand Myer

http://gyazo.com/04acd02b4fb4ea7e46c55c3a64c945b3.png

Method call and member access looks the same

Adopted by various recent languages

JavaScript

Prototype-based OO

Widely used recently

Many "ALT-JS"

CoffeeScript

Typescript

Prototype-based OO

Use existing object as 'prototype'

Proposed in the 80s

Essence of OO

Inheritance?

Information hiding?

Data sharing?

Mapping between real objects and computer objects?

Distributed communication?

Essence of OO

Technique for making programs shorter (Prof. Takeuchi)

Is OO really needed?

OO-like programming possible on C

Not as important as structured programming and recursion?

Unix kernel is not implemented in OO language

Compilers are not implemented in OO language

OO thinking

File system and OO

Japanese and OO

File system and OO

No distinction between file and I/O device

/home/masui/xxx (file) and /dev/xxxx (I/O) are treated as the same

Article by Nakajima-san

"Salt to me"

Not "pass me the salt"

Merits of postfix notation

X.inv.log

log(inv(X))

Development methods