software engineering

Software engineering

Lecture 1 – Software development processes

2

Table of Contents

Part I: Tools for Your OO Toolbox• Sample Application: Book Inventory• Basics of Well Designed Applications• Development Approaches• Applying Practices, Principles and Patterns

Part II: Agile Model Driven Development• AMDD Lifecycle• Sample Application:

Second Hand Store• Initial Modeling• Development

Iterations

3

Main References

[Ambler06] Scott Ambler. Agile Modeling Home Page. http://www.agilemodeling.com/

[Palmer02] Stephen Palmer, and John Felsing. A Practical Guide to Feature-Driven Development. Prentice Hall 2002.

[McLaughling06] Brett McLauhlin et all. Head First Object-Oriented Analysis and Design. O’Reilly, 2006.

[Evans04] Eric Evans. Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison Wesley, 2004.

[Fowler02] Martin Fowler. Patterns of Enterprise Application Architecture. Addison Wesley, 2002.

[Gamma95] Erich Gamma et all. Design Patterns: Elements of Reusable Object Oriented Software. Addison Wesley, 1995.

4

1 Sample Application: Book Inventory

John Doe, the owner of a small second hand store decided to throw out his paper-based system for keeping track of books, and start using a computer based system to store its inventory.

John required a search tool to match the customers need for books.

John hired a computer programming firm, Direct Coding, to build a prototype for book inventory management.

5

2 Basics of Well Designed Applications

2.1 A First, Misguided Solution

2.2 Analyzing the First Solution

2.3 Add Tools to Your OO Toolbox

6

2.1 A First, Misguided Solution

Direct Coding built a prototype for book inventory management.

Direct Coding programmers proceeded as follows:A. they started from requirements, B. built a simple UML model, thenC. they directly implemented their model.

Finally, Direct Coding delegated a programmer to present a prototype of the Book Inventory:

D. John Doe’s acceptance testE. Preparing the prototypeF. Presenting the results

7

A. Requirements Analysis

The programmers extracted from John Doe’s requirements the following requirements list: the second hand store has a book

repository composed of many books.

a search tool is required to match the customers need for books.

Because the programmers know a lot about books they considered it is clear what they have to do.

8

B. Design

Each book is represen-ted as an instance of this class

This class represents the entire second hand’s book repository

Method used to add booksto John’s second hand repository

A unique book number is assigned to each new book

Attributes used to search for books

Here, the mostexpected methodthat returnsbook information

9

C. Implementation (Book)

public class Book { private int bookNumber; ...

public int getBookNumber() { return bookNumber; } ...

public Book(int bookNumber, String isbn, String authors, String title,String publisher, int year, double price) { this.bookNumber = bookNumber; ... } public String toString() { return authors + title + publisher + year; }}

Other fields and theircorresponding gettersnot shown hereto save space...

Other field initializations also not shown...

10

C. Implementation (BookRepository)

import java.util.ArrayList;import java.util.List;

public class BookRepository {

private List<Book> books;

public BookRepository() { books = new ArrayList<Book>(); }

public void add(String isbn, String authors, String title, String publisher, int year, double price) { Book book = new Book(books.size(), isbn, authors, title, publisher, year, price); books.add(book); } //...

All books represented here

11

C. Implementation (BookRepository)

public Book findBook(Book searchBook) { for(Book book: books) { //we ignore bookNumber and price attributes String isbn = searchBook.getIsbn(); if ( (isbn != null) && (!isbn.equals("")) && (!isbn.equals(book.getIsbn())) ) continue; String authors = searchBook.getAuthors(); if ((authors!=null) && (!authors.equals("")) && (!authors.equals(book.getAuthors()))) continue; String title = searchBook.getTitle(); if ( (title != null) && (!title.equals("")) && (!title.equals(book.getTitle())) ) continue; String publisher = searchBook.getPublisher(); if ((publisher != null) && (!publisher.equals("")) && (!publisher.equals(book.getPublisher())) ) continue; float year = searchBook.getYear(); if ( (year != 0) && (year != book.getYear()) ) continue; } return null; }} //end of BookRepository

All searching attributes can be left null or empty.

nulls and empty values satisfies the criteria, so if the non-empty values do not match the book values we continue

12

D. Customer Acceptance Test

John Doe: Could you show me please how can I use

the application in order to find “Implementation Pattern” books written by “Kent Beck”?

Direct Coding enthusiastic representative: (He expects to obtain possible more

than one book... ) Give me please a couple of minutes to

prepare a short test...

13

E. Acceptance Test Implementation (TestBookRepository)

public class TestBookRepository { public static void main(String[] args) { BookRepository repository = new BookRepository(); initializeRepository(repository);

Book bookSpecRequired = new Book(0, "", "Kent Beck", "Implementation Patterns", "", 0, 0); Book book = repository.findBook(bookSpecRequired); if (book != null) { System.out.println("You might like this book: " + book); } else { System.out.println("Sorry, we have nothing for you."); } }

private static void initializeRepository(BookRepository bookRepository) {

bookRepository.add("0321413091", "Kent Beck", "Implementation Patterns", "Addison-Wesley", 2006, 12.5); // other books could also be added }}

Other attributes left empty

Looking for books that havea given author and title.

Particular book repository prepared for John Doe’s requirements

14

F. Acceptance Test Result...

Running the test

John Doe is a little bit disappointed What goes wrong? What’s the first thing they should

change?

15

2.2 Analyzing the First Solution

How do we write great software, every time?

Customer-friendly programmer says: Great software does what the customer

wants it to. OO programmer says:

Great software is object-oriented, not a bunch of duplicate code.

The code should be easily to extend. Design-guru programmer says:

Great software is when you use tried-and-true design patterns and principles.

16

A. Great Software in Three Easy Steps

Don’t create problems to solve problems.

Apply good OO principles and patternsto ensure your application isready to use for years to come.

Apply good OO programmingtechniques (e.g. eliminate duplicate code, etc)

17

B. What’s Wrong with Their Requirements?

An extract from the initial John’s requirements: “We need a search tool to match the

customer needs for books.”But, Direct Coding representative did not investigated what the customer wants.Now they understand that “the search result should return a list of books.”

Modification needed here. The method mustreturn a list of books.

18

C. What’s Wrong with Their Model?

The test class was created after writing the code for search.

The find methodwas not tested before presenting the solution.

Book specification is not encapsulated.A change request, “adda new book spec attribute”, would affect all classes.

Authors and publishers are not strings in the real world!They are entities, so they shouldbe designed as classes.

Book class is responsible for spec attributes and also for holding the price (Violates Single Responsibility Principle).

19

D. What’s Wrong with Their Code?

public Book findBook(Book searchBook) { for(Book book: books) { //we ignore bookNumber and price attributes String isbn = searchBook.getIsbn(); if ( (isbn != null) && (!isbn.equals("")) && (!isbn.equals(book.getIsbn())) ) continue; String authors = searchBook.getAuthors(); if ((authors!=null) && (!authors.equals("")) && (!authors.equals(book.getAuthors()))) continue; String title = searchBook.getTitle(); if ( (title != null) && (!title.equals("")) && (!title.equals(book.getTitle())) ) continue; String publisher = searchBook.getPublisher(); if ((publisher != null) && (!publisher.equals("")) && (!publisher.equals(book.getPublisher())) ) continue; float year = searchBook.getYear(); if ( (year != 0) && (year != book.getYear()) ) continue; } return null; }

Bad smell...A lot of duplicated code...

20

Development Approaches

2.3 Add Tools to Your OO Toolbox

Requirements

Practices

Analysis & Design

OO Principles

Design Patterns

Implementation

A design principle is a basic tool or technique that can be applied to designing or writing code to make that code more maintainable, flexible, or extensible.

Approaches to building, deploying, and possible maintaining software.What tasks/steps could be taken? In which order?

Good ideas to adopt,collected from several development approaches.

Guidelines to consider whileperforming these activities, common to almost all development approaches.

A design pattern is a general repeatable solution to a commonly occurring problem in software design.

21

3 Development Approaches

3.1 Requirements, Practices, and Development Approaches

3.2 Introduction to Agile Model Driven Development (AMDD)

3.3 Introduction to Test Driven Development (TDD)

22

3.1 Requirements, Practices, and Development Approaches

Requirements

Good requirements ensure your system works like your customers expect.

Capture the lists of features your software is supposed to do.

Practices

Developers (who know how to build) and domain experts (who know the domain) should have a close relationship.

Model in small increments – organize a larger effort into smaller portions that you release over time (incremental development).


Feature Driven Development – focuses on a single feature, and codes all the behavior of that feature, before moving on to anything else in the application.

Palmer, 2002 Ambler, 2004

Evans, 2004

23

3.1 Requirements, Practices, and Development Approaches (cont)

A feature is a small, client-valued function expressed in the form <action> <result> <object>, and typically can be implemented within a

few hours.Example: Add a book to the book repository.

But customers prefer long lists of features to be organized in feature setsExample: Administering, Searching

In order to beeasy to make estimates!

Ambler, 2004

24

3.1 Requirements, Practices, and Development Approaches (cont)

Book Inventory Features:1. Administering

a) Add a new book to book repository2. Searching

a) List the books that satisfy a given book specification criteria.

b) List the authors that have registered books into the second-hand store.

c) List the publishers that have registered books into the second hand store.

Model in small increments: 1.a), 2.b), 3.a), etc

Feature sets

Model, and codethis feature

Then, model, and codethis one

25

3.2 Introduction to Agile Model Driven Development (AMDD)

Requirements



Practices




Feature driven development – focuses on a single feature, and codes all the behavior of that feature, before moving on to anything else in the application.

Agile Model Driven Development – focuses on creating just barely good enough models (agile models) before writing the source code.

26

3.2 AMDD (cont)AMDD Development Lifecycle

Activity

Sub activity

The result of each iterationis an executable.

Each iteration focuses to model, and code a subset of the system requirements (e.g. feature 1.a, “add a book to the repository”)

The system grows,incrementally

27

3.2 AMDD (cont)Analysis and Design: Attributes vs. Classes

Example – a “barely” good enough model for the following feature:

“Add a new book to book repository”. How to model authors and publishers? Guideline: Attributes vs. Classes

If we do not think of some thing X as a number or text in the real world, X is probably a conceptual class, not an attribute.

Matching strings to authorsand publisher could be encapsulated in these classes.

Moreover, we need to add these concepts because we mustmanage the list of authors, and publishers.

28

3.2 AMDD (cont) Analysis and Design: Description Classes

How to model the relationships between book and authors, and publishers classes?

A description class contains information that describes something else.

Guideline: When Are Description Classes Useful? Add a description class (for example, BookSpecification) when:

There needs to be a description about an item or service, independent of the current existence of any examples of those items or services.

It reduces redundant or duplicated information.

29

3.2 AMDD (cont) Layered Architecture Pattern

How to organize a complex program?

Layered Architecture Pattern:

Partition a complex program into layers.

Concentrate all the code related to the domain model in one layer and isolate it from the others.

Ensure each layer is cohesive and depends on the layers below.

A layered architecture and typical relationships

between layers

concepts of business, business rules

technical capabilities:messages, persistence, etc

tasks coordinator,jobs, services

show info, andinterpret user’s commands

30

3.2 AMDD (cont)New Tools for Your OOAD Toolbox

RequirementsGood requirements ensure your system works like your customers expect.


PracticesDevelopers (who know how to build) and domain experts (who know the domain) should have a close relationship.


Development ApproachesAgile Model Driven Development – focuses on creating just barely good enough models (agile models) before writing the source code.

Analysis & Design If a design isn’t flexible then,

CHANGE IT! Make sure each class is cohesive

– focused on doing ONE THING really well.

Model things that are not numbers or strings in the real world as concepts.

Use description classes to reduce redundant or duplicate information.

OO PrinciplesSingle Responsibility: Assign

each responsibility to one class, and only one class.

Encapsulation: The grouping of related concepts into one item, such as a class, package, etc.

Design Patterns Layered Architecture:

Partition a complex program into layers.Ensure each layer is cohesive.

Evans, 2004

31

3.2 AMDD (cont) How to implement “adding books” feature?

The refined domain model:

How to implement the model? Is this a good model? Are there other guidelines

for improving the model? What steps could we follow for implementation?

32

3.3 Introduction to Test Driven Development (TDD)

Requirements



Practices




Feature driven development – focuses on a single feature, and codes all the behavior of that feature, before moving on to anything else in the application.

Agile Model Driven Development – focuses on creating just barely good enough models (agile models) before writing the source code.

Test driven development – writes test scenarios for a piece of functionality before writing the code for that functionality. Then you write software to pass all the tests.

Beck, 2002

33

3.3 TDD (cont)

What is it?

TDD = Test First Design + Refactoring

TFD Steps:1. Add just enough code to fail. 2. Run the tests, to ensure that the

new test does in fact fail. 3. Update your functional code to

make it pass the new tests. 4. Run your tests again.

If they fail you need to update your functional code and retest.

Once the tests pass the next step is to start over.

One goal is specification, not validation.

Second, it’s one way to think about your design, before you write your functional code.

Third, it’s a way to write clean code that works.

1

2

3

4

TFD Steps

34

3.3 TDD (cont)Model, and code the Author class

This task can be considered part of the iteration 1: “Add a book to book repository” that can be decomposed as:

Model, and code Author, and Publisher classes, thenModel, and code BookSpecification class, then finallyModel, and code Book class.

Can we implement directly the model for authors? We need to: create Author instances, and match authors by name.

But, another feature requires to “List the authors that have registered books”. How to proceed?An object defined primarily by its identity is called an ENTITY. ENTITY identities must be defined so that they can be effectively tracked.

35


Author instances are entities!

We divide this task in two test-driven development cycles, focused on

Creating Author instances, andMatching authors by name.

Each test-driven development cycle will include the following subtasks:

1. Add a test case.2. Run the tests.3. Implement the required functionality.4. Run the tests again.

Customers may already have such ids for their entities, so the programmer could use them.

A unique integer generated value will be assigned for each Author instance.

36


1 Creating author instances cycle:1.1 Create authors test case

package test;

import domain.Author;

import junit.framework.TestCase;

public class AuthorTest extends TestCase {

public void testCreate(){

final String authorName = "Kent Beck";

Author author = new Author(authorName);

assertEquals(authorName, author.getName()); }

}

The constructor and the getter method do not exist. So, the test case does not compile.

37

1 Creating author instances cycle:1.2 Create authors test case (cont)

package domain;public class Author { private int id; private String name;

public Author(String authorName) { // TODO Auto-generated constructor stub } public String getName() { // TODO Auto-generated method stub

return null; }}

Method bodies not completed (TODO...).

We enhanced our design!!!


Add required elements to

Author class in order tocan run the test case.

38

3.3 TDD (cont) Model, and code the Author class

1 Creating author instances cycle:1.2 Run the tests, to ensure that the new test does in fact fail.

public void testCreate() { final String authorName = "Kent Beck"; Author author = new Author(authorName); assertEquals(authorName, author.getName());}

Failed becausethe methods werenot yet implemented

39


1 Creating author instances cycle:1.3 Update your functional code to make it pass the new tests.

package domain;public class Author { private int id; private String name;

public Author(String authorName) { this.name = authorName; } public String getName() { return name; }}

Method bodies completed.

Now we can run the tests.

40


1 Creating author instances cycle:1.4 Run your tests again.

The tests passed.

The next step is to start over.

41


2 Matching authors cycle:2.1 Matches authors test case

public void testMatches() {final String authorName = “Kent Beck";Author author = new Author(authorName);final String searchAuthorName = “Beck";assertTrue(“Author: " + authorName +

" matches: “ + searchAuthorName, author.matches(searchAuthorName));

}

2.3 Matches author method

public boolean matches(String searchAuthorName) { return name.contains(searchAuthorName);}

42

3.3 TDD (cont)New Tools for Your OOAD Toolbox





Development ApproachesTest driven development – writes test scenarios for a piece of functionality before writing the code for that functionality. Then you write software to pass all the tests.


CHANGE IT! Make sure each class is cohesive –

focused on doing ONE THING really well.



OO PrinciplesSingle Responsibility: Assign each

responsibility to one class, and only one class.




Entity: Determine the entities within your system and establish their identities.

Implementation The basic rhythm for development is to

write a little test code, then write a little production code, make it pass the test, then write some more test code, and so forth.

43

4 Applying Practices, Principles, and Patterns

4.1 Our Development Approach4.2 Project Plan4.3 Iteration Plan4.4 Repository Pattern4.5 Value Object Pattern4.6 Service Layer Pattern

44

4.1 Our Development Approach

Our development approach in this course:For a couple of requirements (features) our system must fulfill consider an iteration For each iteration do:

Break the iteration in work itemsFor each work item/task do:

Model a little bit ahead (if necessary) Break the work item into several TDD small steps and perform for each step:

Add a a little test codeRun the testsAdd a little production codeRun the tests again

TDD steps

AMDD Development iteration steps

FDD practices

In order to save space, the next slides will show only these steps.

Document the result in a project plan.Write the work

items into an iteration plan.

45

4.2 Project Plan

A project plan gathers all information required to manage a project. For simplicity, we are going to consider

only the iteration plan (part of a project plan).

Book Inventory Project Plan FragmentIteration Requirement (Feature)

I1 Add a new book to book repository

I2 List the authors that have registered books into the second-hand store.

I3 List the books that satisfy a given book specification criteria.

I4 List the publishers that have registered books into the second hand store.

46

4.3 Iteration Plan (I1)

Name/Description Priority State Assigned To

Author class: creating instances, matching authors

1 Done Mary

Tracking author instances 2

Tracking Publisher instances 2

BookSpecification class 3

Book class 4

Tracking Book instances 5

Iteration I1. Add a new book to book repositoryIteration Workitems/Tasks

Tasks to be performed in this iteration.

In which order?Who should perform the task?

47

4.4 Repository Pattern

Context/Problem: Some objects must be globally accessible

through a search based on object attributes. Free database queries can actually breach the

encapsulation of domain objects. Exposure of technical infrastructure and

database access mechanisms complicates the client and violates Layered Architecture.

Solution: For each type of object that needs global access,

create an object (called Repository) that can provide the illusion of an in-memory collection of all objects of that type.

Provide methods to add and remove objects.

Provide methods that select objects based on some criteria and return fully instantiated objects whose attribute values meet the criteria.

Repository objects encapsulate the actual storage and query technology.

e.g. Author A respon-sible layer must be chosen.

Do not chooseui, or app!!!

e.g. AuthorRepository, put in domain

48

4.4 Repository Pattern (cont)Iteration 1. Task - Tracking Author Instances

Model a bit ahead• Repository pattern applied

TDD Cycle 1: Add an author to the repositoryAdd author test casepublic void testAddAuthor() { AuthorRepository authorRepository = new AuthorRepository(); Author author = new Author("Kent Beck"); assertTrue(author.getId() == 0); authorRepository.add(author); assertFalse(author.getId() == 0);}

Add author production codeprivate List<Author> authors;

public AuthorRepository() { authors = new ArrayList<Author>(); }public void add(Author author) { author.setId(authors.size()+1); authors.add(author);}

AuthorRepository class added to domain layer

Model storming result

The model after adding the test caseNew

methods designed

Author.idset by repository

49

4.4 Repository Pattern (cont)Iteration 1. Task - Tracking Author Instances (cont)

TDD Cycle 2: Find all authorsFind authors test case

public class AuthorRepositoryTest extends TestCase { private AuthorRepository authorRepository; protected void setUp() throws Exception { authorRepository = new AuthorRepository(); super.setUp(); } protected void tearDown() throws Exception { authorRepository = null; super.tearDown(); } public void testGetAuthors() { assertTrue(authorRepository.getAuthorSize() == 0); Author author1 = _addAuthor(“Kent Beck”); assertTrue(authorRepository.getAuthorSize() == 1); Author author2 = _addAuthor(“Martin Fowler”); List<Author> authors = authorRepository.getAuthors(); assertTrue( ((authors.get(0) == author1) &&

(authors.get(1) == author2)) || (authors.get(1) == author1) && (authors.get(0) == author2));

} private Author _addAuthor(String authorName) { Author author = new Author(authorName); authorRepository.add(author); return author; }}

setUp called before execu-ting each testXxx() method. We initialize authorRepository.

tearDown called after each testXxx() method is executed.

Don’t forget to call the base classmethod!

Running the tests - possible execution paths:1,3,2,1,4,2 OR 1,4,2,1,3,2

Don’t assume the order in which tests within a test case run!

50

4.4 Repository Pattern (cont)Iteration 1. Task - Tracking Author Instances (cont)

TDD Cycle 2: Find all authorsFind authors production code

...private List<Author> authors;...public int getAuthorSize() { return authors.size();}

public List<Author> getAuthors() { return authors;}

The model after adding the test cases

”add author”, and “find all authors”

51

4.4 Repository Pattern (cont) Iteration 1. Task - Tracking Publisher Instances

Similar steps as for authors can be applied to develop a solution for this task

Add publisher ang get publishers methods go here...

Publisher identifier must be established.Getters and matching publisher methods must be added.

52

4.5 Value Object Pattern

An object that represents a descriptive aspect of the domain with no conceptual identity is called a value object.

Value objects are instantiated to represent elements of the design that we care about only for what they are, not who or which they are.

When you care only about the attributes of an element of the model, classify it as a value object.

Treat the value object as immutable. (it cannot be changed except by full replacement)

Don't give it any identity.Book Specification can be considered here a value object: “John does not require to track its identity”.

In other settings Book Specification could be an entity!! (if the customer requires to track such information by identity)

53

4.5 Value Object Pattern (cont) Iteration 1. Task – Book Specification Class

Model a bit ahead• Value object pattern applied

TDD Cycle 1: Create a book specificationAdd a test case

public void testCreate() { BookSpecification bs = new

BookSpecification(); bs.setIsbn("0321413091"); bs.setTitle("Implementation Patterns"); bs.setYear(2006); Author author = new Author("Kent Beck"); bs.addAuthor(author); bs.setPublisher(new Publisher("Addison-

Wesley")); //... assert methods not shown to save

space}

Add production code//Also not shown to save space...

54

4.5 Value Object Pattern (cont) Iteration 1. Task – Book Class

Model a bit ahead• Value object pattern applied

TDD Cycle 1: Create a book specificationAdd a test case

public void testCreate() { BookSpecification bs = new BookSpecification(); //set attributes for bs... //add also the authors and set the publisher

Book book = new Book(); book.setBookSpecification(bs); book.setPrice(120.5); //... assert methods not shown to save space}

Add production code//Also not shown to save space...

55

4.6 Service Layer Pattern

Defines an application's boundary with a layer of services that establishes a set of available operations and coordinates the application's response in each operation. It encapsulates the application's

business logic, controlling transactions and coordinating responses in the implementation of its operations.

BookInventoryService class

56

4.6 Service Layer Pattern (cont)Iteration 1. Task - Tracking Book Instances

Model (Service Layer Pattern Applied) Usually a service method uses several entity repositories (add, remove, and select operations).

Methods not shown

Methods to bedesigned

57

New Tools for Your OOAD Toolbox






CHANGE IT! Make sure each class is cohesive –

focused on doing ONE THING really well.



OO PrinciplesSingle Responsibility: Assign each

responsibility to one class, and only one class.


Implementation The basic rhythm for development is to

write a little test code, then write a little production code, make it pass the test, then write some more test code, and so forth.

Development ApproachesFeature Driven Development – focuses on a single feature, and codes all the behavior of that feature, before moving on to anything else in the application.Agile Model Driven Development – focuses on creating just barely good enough models (agile models) before writing the source code.Test driven development – writes test scenarios for a piece of functionality before writing the code for that functionality. Then you write software to pass all the tests.

Good software development usuallyincorporates all of these development models at different stages of the development cycle.



Entity: Determine the entities within your system and establish their identities.

Repository: For each type of object that needs global access, create an object (called Repository) that can provide the illusion of an in-memory collection of all objects of that type.

Value Object: When you care only about the attributes of an element of the model, classify it as a value object.

Service Layer: Defines an application's boundary with a layer of services that encapsulate the application's business logic.

58

Part II: Agile Model Driven Development

1. AMDD Lifecycle2. Sample Application:

Second Hand Store3. Initial Modeling4. Development

Iterations

Presents Agile Model Driven Developmentproject phases & iterations.

A more complex case study.Several solutions will be investigated during the nextcourses.

• How to use UML Use Cases for gathering requirements.• How to build a Conceptual Model.

UML tools: • Sequence diagrams, • Class diagrams.Basic GRASP Patterns: • Controller, Expert, Creator, • Low Coupling, High Cohesion.

59

Main References

[Larman04] Craig Larman. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, Third Edition. Addison Wesley, 2004.

[Ambler04] Scott Ambler. The Object Primer, Agile Model Driven Development. Third Edition. Cambridge University Press, 2004.

[Ambler06] Scott Ambler. Agile Modeling Home Page. http://www.agilemodeling.com/

[Fowler03] Martin Fowler. UML Distilled: A Brief Guide to the Standard Object Modeling Language. Addison Wesley, 2003.

[McLaughling06] Brett McLauhlin et all. Head First Object-Oriented Analysis and Design. O’Reilly, 2006.

60

1 AMDD Lifecycle

1.1 Project View

1.2 General Agile System Development Lifecycle

1.3 Iteration 0: Initial Modeling

1.4 Iteration k: Development Iteration

Presents activities performed when a new system is developed.

Another perspective that shows phases and iterations.

Presents subactivities or tasksusually performed before starting the development iterations.

Emphasizes on “model storming” activities performed during development iterations.

61

1.1 Project View

62

1.2 General Agile System Development Lifecycle

AMDD PrincipleAMDD Activities

63

1.3 Iteration 0: Initial Modeling

Identify some high-level requirements as well as the scope of the project (what you think the system should do). Usually the following models are helpful:

Usage models: o Features, and o UML Use Cases.

Initial domain model, or conceptual model:o UML Class Diagrams

User interface model:o Screen Sketches

Initial architecture modeling

Performed during the first week of a project, or the first two weeks for large projects.

How users will work with your system.

Fundamental business entity types and the relationships between them. Your modeldoesn’t need to be complete, just to cover enough info to make you comfortable with domain business entities.

For UI intensive projects.

Identify an architecture that has a good chance of working.

64

1.4 Iteration k: Development Iteration

Model Storming System Operations

UML Sequence Diagram, Operation Contracts

Object Collaboration: UML Sequence Diagram GRASP: Expert, Creator, Controller,

Low Coupling, High Cohesion Design Class Diagram

How system objects collaborate to realize the system operations.

Basic General ResponsibilityAssignment Patterns that can guide us to build a flexible design.

Include object operations into the currentdesign diagram.

What operations should be provided by the system in orderto fulfill use case scenarios.

65

2 Sample Application: Second Hand Store (SHS)

SHS is a consignment shop that gets items from clients and sell them for a percentage of the profits.

Feature list: Add new items to SHS repository. SHS sells the following

type of products: books and music (CDs and DVDs). Update price and profit percentage for an existing item. Capture sales locally. Make payments for sold items of a given client. Sell items online. Show items status of a given client.

Supporting requirements: Allow to increase sales with effective customer and client

relations. Include special offers. For example:

o Buy items together to save a given amount.o Free super saver shipping on orders over a given

amount.

66

3 Initial Modeling

SHS - Iteration 03.1 Usage Models

Requirements list UML Use cases, scenarios

3.2 Initial Domain Model or Conceptual Model UML class diagrams Guidelines

3.3 Initial Architecture Modeling Logical architecture

3.4 Project Planning Plan iterations

67

3.1 Usage Models

What is a requirement?A requirement is a specific thing (capability, condition) your system must conform.

How to capture requirements?Features are for customer, requirements are for developer...Get features from the customers then figure out the requirements you need to implement those features.Feature Listo Add new items to SHS repository. o Capture sales locally.o Make payments for sold items

of a given client....

Requirements List1. Seller registers a contract for a client.2. A contract includes many items.3. The client and seller agree on the price for each item.4. ...

All these req. corres-ponds tothe first feature.

Write a requirement as a complete sentence, with a subject and a predicate (usually a verb).

Subject is an actor, or a design entity.

Define one requirement at a time.

Avoid conjunctions (and, or) that make multiple requirements

68

3.1 Usage Models (cont)

How to outline the requirements?A use case describes what your system does to accomplish a particular customer goal.Each use case includes one or more scenarios that convey how the system should interact with the end user or another system to achieve a particular goal.An actor is something with behavior, such as a person (identified by role), computer system, or organization;A use-case model is a model of the system use cases and actors and the relationships between them. Create a use case model

Use case

Actor

System boundary

69


Detail some use cases and scenarios Some use cases and scenarios may need to be described in more detail to validate our understanding of the requirement and to permit software development to begin. This does not imply that all use cases and scenarios will be detailed prior to commencing implementation. Work with stakeholders to detail only

o those that are prioritized for implementation in the next iteration or two, or

o those that are deemed architecturally significant.

70


How to detail use cases?Use cases format

o high-ceremony use cases - formal, highly structured

o low-ceremony use cases - informal, less rigidly structured; also called briefs.

Use a high ceremony format for use cases planned to be implemented in the next iteration or two.Use a brief format for the rest of use cases.

Use case: Browse itemsCustomers can search for items sold by SHS.Some items can be collected into a shopping cart.Later, the shopping cart items will be used to make an

order.

Brief format

Free description

71


Use case: Register contractDescription: Register a contract for a clientActors: SellerPreconditions: Seller is authenticated.Postconditions: A new contract was created.Normal flow1. System shows the list of clients2. Seller selects a client3. System shows existing client’s contracts 4. Seller make a new contract5. Seller enters a client item This step may repeat.6. Seller submit the contract7. System registers submitted contract8. A contract form is printedAlternative Flows2a. New client 1. Seller enters the new client information*a. At any time, System fails 1. Seller retries to restart register contract5a. Invalid/incomplete item data 1. System reports missing item data 6a. Invalid/incomplete contract data 1. System reports missing contract data and returns to step 5

High-ceremony (formal) format

Conditions that must hold. What is changed after executing the steps below.

Normal flow capture sequentially the steps typically performed by the actors.

This is like a conversation:• Actor ...• System ... No technical terms used,

such as UI widgets, database, etcInstead of “System saves the contract”, we write “System registers the contract”.In case of a new client,

the seller performs this step(there could be more than one step here).

Scenarios: (a) 1,2,3,4,5,6,7,8; (b) 1,2a,3,4,5,5a,5,6a,7,8; etc

72

3.2 Initial Domain Model or Conceptual Model

Define a conceptual model if the model help you to have a big picture of the business entities and transactions.

Business transactions –representthe mainfocus ofbusiness in the SHSdomain

The model should be easily readable.Even the stakeholder should be able to read it.

A contract is signed by a client.A client may have many contracts.

Use labels on associations to make model readable.

Capture attributes ifthe requirements specify them.

73

3.3 Initial Architecture Modeling

Logical Architecture - is the large-scale organization of the software classes into packages (or namespaces), subsystems, and layers. Define the layering strategy for the software architecture. As a minimum, decide on:

The number of layers. Their names and purposes. Their relationships to

one another.

UI classes will use services in order to obtain domain objects.

Services will use repository objects in order to obtain domain objects.Repository objects will use concrete

infrastructure frameworks to manage persistent objects, or concrete communication framework to manage remote objects.

Domain objects will remain technically indepen-dent.

74

3.4 Project Planning

Iteration Requirements (Use cases, scenarios)

I1 Sign InRegister contract – Normal Flow

I2 Register contract – Alternative flows

I3 Register sale

I4 Make payment

I5 Web sign inBrowse items

I6 Fulfill order

I7 View item status

Iteration plan(part of project plan)

Usually there are at least another two columns related to start and end dates. But this is an intro course...

The first iteration includes an entire use case and a single scenario from another use case.

75

Initial Modeling Summary

Initial modeling tasksGet features from the customers then build a requirements listCreate a use case modelDetail some use cases and scenariosDefine a conceptual modelDefine the layering strategy for the software architectureBuild an iteration plan

Usually perfor-med in this order.

Requirements express details of the features put in an appropriate format for developers.Let’s have a big picture of

those requirements that require interactions between our system and external actors.

Most important/critical; we are going to start with them.To have a better

understanding of the business entities.

A working logical architecture for the system.

Map requirements to development iterations.

76

4 Development Iterations

AMDD development iteration steps1. Model the current iteration

scenarios or tasks model services, and controllers model entities, repositories

2. Write unit tests

3. Implement business logica) we return several

times to write unit tests (according to TDD)

b) we also make model stormingsessions when necessary

4. Implement the front-end

Domain & App/Service(barely good) models

UI layer implementation

Fix and improve the models by writing unit tests

Domain & service layers production code

77

4 Development Iterations (cont)

AMDD development iteration steps plus UML artifacts4.1 Determine iteration tasks

A. Refine the domain modelB. Determine the system behavior

Write a system sequence diagram for each scenarioWrite system operation contracts

C. Model controllers and servicesD. Make a work item/task list

4.2 Model then implement each work itemA. Establish object collaboration for each system operationB. Model entities and repositoriesC. Applying TDD

Write unit testsImplement business logic

D. Implement the front-end

Include concepts related to the current iteration

78

4.1 Determine iteration tasks

Determine iteration tasks refers initiating the iteration and assigning work items to team

members. But how to determine the work items?

Make a model storming sessiono try to make some investigations in order to understand

what is needed to implement current iteration scenarios.

Iteration 1 Workitems/Tasks


Sign in

...

Register contract

Normal flow

...

•These are use cases.•This is a complex scenario within a use case •We need to make some analysis to detail what is needed to implement the scenarios.

79

4.1 – A. Refine the Domain Model

Make a Domain Model for the Current Iteration.Why? In order to obtain a list of concepts that must be implemented for the current iteration.How to Create a Domain Model?

o Bounded by the current iteration requirements under design:

– Find the conceptual classes.– Draw them as classes in a UML class diagram.– Add associations and attributes.

How to Find Conceptual Classes?o Three Strategies to Find Conceptual Classes:

– Reuse or modify existing models.– Identify noun phrases.– Use a category list.

For this iteration we are going to use this method.In future iteration

we are going to use this method.

80

4.1 – A. Refine the Domain Model (cont)

Finding Conceptual Classes with Noun Phrase Identification: Identify the nouns and noun phrases in textual

descriptions of a domain, and consider them as candidate conceptual classes or attributes.

Iteration 1 Requirements (Register contract – normal flow)

1. System shows the list of clients2. Seller selects a client3. System shows existing client’s contracts 4. Seller make a new contract5. Seller enters a client item This step may repeat.6. Seller submit the contract7. System registers submitted contract8. A contract form is printed

Name an association based on a ClassName-VerbPhrase-ClassName format where the verb phrase creates a sequence that is readable and meaningful.

81

4.1 – A. Refine the Domain Model (cont)

Model also other requirements related to current scenarios (requirements not specified in use cases but present in our requirements list).For example, we include details about item descriptions.

Apply UML roles and multiplicities.

82

4.1 – B. Determine the System Behavior

Can we write now the work items and then to code?No. A domain model shows a static view of the system.

o There is no indication about how to start and code the scenario requirements.

But how to model the steps from our use case scenarios?

Determine thesystem behavior, that is the system public interface thatshows all operationsthat must be implemented.

In a layered architecture context, until now, we only have a big picture of the main business entities.

83

4.1 – B. Determine the System Behavior (cont)

How to proceed?A system sequence diagram is a picture that shows, for one particular scenario of a use case, the events that external actors generate.

Write a system sequence diagram for each scenario

An actor generates system events to a system, usually requesting some system operation to handle the event.

84


System Behavior for Register contract normal flow

System event/user request

a response.

System must perform a computation to give...

That’s a system operation.

System viewed as a black box

The entire set of system operations, across all use cases, defines the public system interface

85


But how the system operation is related to methods from OO programming languages?

A system operation will become a method of a class of our system under development.

What to do next?Write system operation contracts, that capture what the user expects from the system.How to do? Express the contracts in terms of domain model concepts.

86


How to write system operation contracts?Use the following template for system operation contracts:

o Operation: Name of operation, and parameterso Description: What operation does.o Cross References: Use cases this operation can occur

withino Preconditions: Assumptions about the state of the

system or objects in the domain before execution of the operation.

o Postconditions: The state of objects in the domain after completion of the operation.

To describe the post conditions, use the following categories:o instance creation and deletiono attribute modificationo associations formed and broken

87


getClients(): List<Client>A list containing all clients is returned.

getClientContracts(c: Client): List<Contract>A list containing all contracts of a given

client is returned.Pre: c is not null

makeNewContract(c: Client)Post: A new contract was created.

This is called the current contract.enterItem(item info)

Pre: A contract is edited (created or updated).Post: A new item was created.

The item was added to the current contract.contractCompleted()

Pre: A contract was edited (created or updated).Post: The current contract was registered or updated.

Precondition is true (no assumptions about the state of the system)

Postconditions are true (the state of the system has not changed)

These operations change the state of the system (we have postconditions).

88


System behavior for use case sign in

signin(username:String, password:String): boolean

Post: Returns true if there is a seller having this pair (username, password), and in this case the seller is authenticated. Returns false, otherwise.

signin operation contract.

89

4.1 – C. Model Controllers and Services

GRASP Pattern: Controller Problem: What first object beyond the UI layer receives and coordinates ("controls") a system operation?Solution: Assign the responsibility to a class representing one of the following choices:

o Represents the overall "system," a "root object," a device that the software is running within, or a major subsystem; these are all variations of a facade controller.

o Represents a use case scenario within which the system event occurs, often named <UseCaseName>Handler, <UseCaseName>Coordinator, or <UseCaseName>Session (use case or session controller).

90

4.1 – C. Model Controllers and Services (cont)

Applying Controller and Service Layer Patterns

Programmer X

Programmer Y

Programmer Z

91

4.1 – D. Make a work item/task list


Sign in X

Signin Form

SHS Controller

Security Service

Seller entity and Seller Repository

Register contract

Normal flow

Contract form, controller, and service

Y

Supporting entities and repositories for contract service

Z

An entire use case assigned to a developer.This developer will work across all layers (ui, service, domain).

This scenario of a use case was decomposed in two tasks, assigned to different developers.

92

4.1 Determine Iteration Tasks Summary

4.1 Determine iteration tasksA. Refine the domain modelB. Determine the system behavior

Write a system sequence diagram for each scenarioWrite system operation contracts

C. Model controllers and servicesD. Make a work item/task list

4.2 Model then implement each work itemA. Establish object collaboration for each system operationB. Model entities and repositoriesC. Applying TDD



Include concepts related to the current iteration

Now the developers can work independently.They are going to make “model storming” sessions together because there are some dependencies between their work artifacts.

93

4.2 Model, then Implement Each Work Item

A. Establish object collaboration for each system operationB. Model entities and repositoriesC. Applying TDD



94

4.2 – A. Establish object collaboration (cont)

For each system operation a UML sequence diagram can help us to have a big picture about how objects collaborate to realize that operation.

UI objects Domain objects

Service object

System operation assigned to controller objects

Is this responsibility assignment a good one? That is, “controller creates Item instances”.

And, what about this one? NO.

Other useful models could be: state machine diagrams or activity diagrams...

95


GRASP: Information ExpertWhat is a basic principle by which to assign responsibilities to objects?Assign a responsibility to the class that has the information needed to fulfill it.

– Question: “Who should compute the contract total”? – Answer: Contract class.

General Responsibility Assignment Pattern

Responsibility: “a computation the system must perform”.

96


GRASP: CreatorWho creates an A?Assign class B the responsibility to create an instance of class A if one of these is true (the more the better):1. B "contains" or compositely aggregates A.2. B records A.3. B closely uses A.4. B has the initializing data for A.

Examples:Who creates an Item? • Contract – according to 1• ContractService – see 4• RegisterContractController – see 4Who creates a Contract?• SHStore – see 2• ContractService – see 3• RegisterContractController – see 4

But, which is better?Are there any other advices?

97


GRASP: Low CouplingHow to support low dependency, low change impact, and increased reuse?Assign a responsibility so that coupling remains low. Use this principle to evaluate alternatives.

Coupling is a measure of how strongly one element is connected to, has knowledge of, or relies on other elements.

An element (class, subsystem) with low (or weak) coupling is not dependent on too many other elements; A class with high (or strong) coupling relies on many other classes. Such classes may be undesirable.

Who creates an Item? According to GRASP Creator the candidate classes

are: Contract, ContractService, andRegisterContractController

Low coupling suggests that ContractServiceand RegisterContractController should let the Contract class to create Item instances in order to minimize their dependencies.

Low coupling suggests to not create Items in these classes

98


GRASP: High CohesionHow to keep objects focused, understandable, and manageable, and as a side effect, support Low Coupling?Assign a responsibility so that cohesion remains high. Use this to evaluate alternatives.

In terms of object design, cohesion (or more specifically, functional cohesion) is a measure of how strongly related and focused the responsibilities of an element are. An element with highly related responsibilities that does not do a tremendous amount of work has high cohesion.

Very low cohesion - A class is solely responsible for many things in very different functional areas.Low cohesion - A class has sole responsibility for a complex task in one functional area. High cohesion - A class has moderate responsibilities in one functional area and collaborates with other classes to fulfill tasks.Moderate cohesion - A class has lightweight and sole responsibilities in a few different areas that are logically related to the class concept but not to each other.

99


GRASP Pattern: Pure FabricationProblem: What object should have the responsibility, when you do not want to violate High Cohesion and Low Coupling, or other goals, but solutions offered by Expert (for example) are not appropriate?Solution: Assign a highly cohesive set of responsibilities to an artificial or convenience class that does not represent a problem domain concept something made up, to support high cohesion, low coupling, and reuse.

Such a class is a fabrication of the imagination. Ideally, the responsibilities assigned to this fabrication support high cohesion and low coupling, so that the design of the fabrication is very clean, or pure hence a pure fabrication.

100


GRASP Pattern: Indirection Problem: Where to assign a responsibility, to avoid direct coupling between two (or more) things? How to de-couple objects so that low coupling is supported and reuse potential remains higher?Solution: Assign the responsibility to an intermediate object to mediate between other components or services so that they are not directly coupled.

The intermediary creates an indirection between the other components.

101


System Operation: getClients(): List<Client>

by Controller

by Service Layer

by Repository

getAllClients() is a message sent between objects. A method will be added in the target class.

In a desktop app, frame instances call this op.

Moreover, the required visibilities between objects are:• ContractService must be visible to RegisterContractController.• ClientRepository must be visible to ContractService.

We are going to return to solve the visibility between objects later when applying TDD steps. This is not a complete model. Just a “barely good enough” model.

102


System Operation: getClientContracts(client:Client): List<Contract>

by Controller

by Service Layer

by Repository

This diagram repeats the previous simple decisions used also for getClients() system operation.

So, for simple system operations we can avoid draw object collaboration diagrams. We can apply the above patterns when we code the unit tests (the next step after this model step).

103


by Controller

by Creator

by Low Coupling, Indirection

by Creator

by Expert

by Service Layer

by Repository

But, how to update UI in order to show the total?

This sequence diagram captures the remaining of system operations.

104

4.2 – B. Model entities and repositories

105

4.2 – B. Model entities and repositories

106

4.2 – C. Applying TDD

Designing for visibility visibility is the ability of an object to "see" or have a

reference to another object Is one resource (such as an instance) within the scope

of another?Four common ways that visibility can be achieved from object

A to object B: Attribute visibility: B is an attribute of A. Parameter visibility: B is a parameter of a method of A. Local visibility: B is a (non-

parameter) local object in a method of A.

Global visibility: B is in some way globally visible.

Sequence Diagram

107

4.2 – C. Applying TDD

Sequence Diagram

108

4.2 – D. Implement the Front-End

Initialization and the 'Start Up' Use CaseWhen to Create the Initialization Design?

Do the initialization design last.How do Applications Start Up?

create an initial domain object or a set of peer initial domain objects that are the first software "domain" objects created

once created, they will be responsible for the creation of their direct child domain objects.

Choosing the Initial Domain Object Choose as an initial domain object a class at or near

the root of the containment or aggregation hierarchy of domain objects.

This may be a facade controller or some other object considered to contain all or most other objects, such as a SHStore.

109


How to Connect the UI Layer to the Domain Layer?Common designs by which objects in the UI layer obtain visibility to objects in the domain layer include the following: An initializer object (for example, a Factory

object) called from the application starting method (e.g., the Java main method) creates both a UI and a domain object and passes the domain object to the UI.

A UI object retrieves the domain object from a well-known source, such as a factory object that is responsible for creating domain objects.

110


Guideline: Model-View Separation PrincipleWhat kind of visibility should other packages have to the UI layer? How should non-window classes communicate with windows? This principle has at least two parts:

Do not connect or couple non-UI objects directly to UI objects. Why? Because the windows are related to a particular application, while (ideally) the non-windowing objects may be reused in new applications or attached to a new interface.

Do not put application logic in the UI object methods. UI objects should only initialize UI elements, receive UI events (such as a mouse click on a button), and delegate requests for application logic on to non-UI objects (such as domain objects).

111


Observer/Publish-Subscribe (GoF Pattern)Problem: Different kinds of subscriber objects are interested in the state changes or events of a publisher object, and want to react in their own unique way when the publisher generates an event. Moreover, the publisher wants to maintain low coupling to the subscribers. What to do?Solution (advice): Define a "subscriber" or "listener" interface. Subscribers implement this interface. The publisher can dynamically register subscribers who are interested in an event and notify them when an event occurs.

112


Model-View-Controller Pattern

Holds all data, state, and application logic

Model send notifications of state changes to the views

Show a presentationof themodel.Usuallygets data directly from the model.

Takes the user input and figure out what it means to the model.

1

23

4

5

Interactions•desktop ui: 1,2, 4,5•web ui: 1,2,3,5;

MVC Model 2

ClassicalMVC

software engineering

Documents

book inventorybasics

designeach book

book inventory management

hands book repositorymethod

book inventoryjohn doe

track of books

string title

string publisher