Software engineering
This presentation is the property of its rightful owner.
Sponsored Links
1 / 112

Software engineering PowerPoint PPT Presentation


  • 94 Views
  • Uploaded on
  • Presentation posted in: General

Software engineering. Lecture 1 – Software development processes. 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

Download Presentation

Software engineering

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Software engineering

Software engineering

Lecture 1 – Software development processes


Table of contents

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


Main references

Main References


1 sample application book inventory

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.


2 basics of well designed applications

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


2 1 a first misguided solution

2.1 A First, Misguided Solution

Direct Coding built a prototype for book inventory management.

Direct Coding programmers proceeded as follows:

  • they started from requirements,

  • built a simple UML model, then

  • they directlyimplemented their model.

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

  • John Doe’s acceptance test

  • Preparing the prototype

  • Presenting the results


A requirements analysis

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.


B design

B. Design

This class represents the entire second hand’s book repository

Here, the most

expected

method

that returns

book information

Method used to add books

to John’s second hand repository

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

A unique book number

is assigned

to each new book

Attributes used to search for books


C implementation book

C. Implementation (Book)

Other fields and their

corresponding getters

not shown here

to save space...

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 field initializations

also not shown...


C implementation bookrepository

C. Implementation(BookRepository)

All books represented here

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

}

//...


C implementation bookrepository1

C. Implementation (BookRepository)

All searching attributes can

be left null or empty.

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

nulls and empty values satisfies the

criteria, so if the non-empty values

do not match the book values we continue


D customer acceptance test

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


E acceptance test implementation testbookrepository

E. Acceptance Test Implementation (TestBookRepository)

Looking for books that have

a given author and title.

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

Particular book repository prepared for John Doe’s

requirements


F acceptance test result

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?


2 2 analyzing the first solution

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.


A great software in three easy steps

A. Great Software in Three Easy Steps

Don’t create problems

to solve problems.

Apply good OO programming

techniques (e.g. eliminate

duplicate code, etc)

Apply good OO

principles and patterns

to ensure your application is

ready to use for years

to come.


B what s wrong with their requirements

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 must

return a list of

books.


C what s wrong with their model

C. What’s Wrong with Their Model?

The test class was

created after writing the

code for search.

The findmethod

was not tested

before presenting

the solution.

Book class is responsible for

spec attributes and also for

holding the price (Violates

Single Responsibility Principle).

Book specification

is not encapsulated.

A change request, “add

a new book spec attribute”,

would affect all classes.

Authors and publishers

are not strings in the real world!

They are entities, so they should

be designed as classes.


D what s wrong with their code

D. What’s Wrong with Their Code?

Bad smell...

A lot of duplicated 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;

}


2 3 add tools to your oo toolbox

2.3 Add Tools to Your OO Toolbox

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.

  • Development Approaches

Guidelines to

consider while

performing

these activities,

common to almost

all development

approaches.

  • Practices

  • Requirements

  • OO Principles

  • Analysis & Design

  • Implementation

  • Design Patterns

A design pattern is a general

repeatable solution to a

commonly occurring problem in

software design.

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.


3 development approaches

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)


3 1 requirements practices and development approaches

3.1 Requirements, Practices, and Development Approaches

Evans, 2004

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

Requirements

Good requirements ensure your system works like your customers expect.

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

Development Approaches

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


3 1 requirements practices and development approaches cont

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 sets

  • Example:

    • Administering, Searching

Ambler, 2004

In order to be

easy to make

estimates!


3 1 requirements practices and development approaches cont1

3.1 Requirements, Practices, and Development Approaches (cont)

Book Inventory Features:

  • Administering

    • Adda new book to book repository

  • Searching

    • Listthe books that satisfy a given book specification criteria.

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

    • Listthe 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 code

this feature

Then, model, and code

this one


3 2 introduction to agile model driven development amdd

3.2 Introduction to Agile Model Driven Development (AMDD)

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

Requirements

Good requirements ensure your system works like your customers expect.

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

Development Approaches

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.


3 2 amdd cont amdd development lifecycle

3.2 AMDD (cont)AMDD Development Lifecycle

Each iteration focuses to model, and code a subset

of the system requirements

(e.g. feature 1.a, “add a book to the repository”)

Activity

Sub activity

The system grows,

incrementally

The result of each iteration

is an executable.


3 2 amdd cont analysis and design attributes vs classes

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 must

manage the list of authors, and publishers.


3 2 amdd cont analysis and design description classes

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.


3 2 amdd cont layered architecture pattern

3.2 AMDD (cont)Layered Architecture Pattern

A layered architecture

and typical relationships

between layers

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

show info, and

interpret user’s commands

tasks

coordinator,

jobs, services

concepts of

business,

business rules

technical capabilities:

messages, persistence, etc


3 2 amdd cont new tools for your ooad toolbox

3.2 AMDD (cont)New Tools for Your OOAD Toolbox

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

Requirements

Good requirements ensure your system works like your customers expect.

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

  • 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 Principles

  • Single 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.

Development Approaches

Agile Model Driven Development – focuses on

creating just barely good enough models

(agile models) before writing the source code.

Evans, 2004


3 2 amdd cont how to implement adding books feature

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?


3 3 introduction to test driven development tdd

3.3 Introduction to Test Driven Development (TDD)

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

Requirements

Good requirements ensure your system works like your customers expect.

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

Development Approaches

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


3 3 tdd cont what is it

3.3 TDD (cont)What is it?

One goal is specification,

not validation.

Second, it’s one way

to think about your

design, before you

write your functional

code.

TDD =

Test First Design + Refactoring

TFD Steps:

  • Add just enough code to fail.

  • Runthe tests, to ensure that the new test does in fact fail.

  • Update your functional code to make it pass the new tests.

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

1

2

3

4

Third, it’s a way to

write clean code that works.

TFD Steps


3 3 tdd cont model and code the author class

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, then

    • Model, and code BookSpecification class, then finally

    • Model, 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.


3 3 tdd cont model and code the author class1

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

  • Author instances are entities!

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

    • Creating Author instances, and

    • Matching 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.

A uniqueinteger generated value will be assigned for each Author instance.

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


3 3 tdd cont model and code the author class2

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

  • 1 Creating author instances cycle:

    • 1.1 Create authors test case

      package test;

      import domain.Author;

      import junit.framework.TestCase;

      publicclass AuthorTest extends TestCase {

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


3 3 tdd cont model and code the author class3

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

  • 1 Creating author instances cycle:

    • 1.2 Create authors test case (cont)

      package domain;

      publicclass Author {

      privateint id;

      private String name;

      public Author(String authorName) {

      // TODO Auto-generated constructor stub

      }

      public String getName() {

      // TODO Auto-generated method stub

      returnnull;

      }

      }

Add required elements to Author class in order tocan run the test case.

We enhanced our design!!!

Method bodies not completed (TODO...).


3 3 tdd cont model and code the author class4

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.

Failed because

the methods were

not yet implemented

public void testCreate() {

final String authorName = "Kent Beck";

Author author = new Author(authorName);

assertEquals(authorName, author.getName());

}


3 3 tdd cont model and code the author class5

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

  • 1 Creating author instances cycle:

    • 1.3 Update your functional code to make it pass the new tests.

      package domain;

      publicclass Author {

      privateint id;

      private String name;

      public Author(String authorName) {

      this.name = authorName;

      }

      public String getName() {

      returnname;

      }

      }

Method bodies

completed.

Now we can run the tests.


3 3 tdd cont model and code the author class6

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

  • 1 Creating author instances cycle:

    • 1.4 Run your tests again.

The tests passed.

The next step is

to start over.


3 3 tdd cont model and code the author class7

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

  • 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);

      }


3 3 tdd cont new tools for your ooad toolbox

3.3 TDD (cont)New Tools for Your OOAD Toolbox

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

Requirements

Good requirements ensure your system works like your customers expect.

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

  • OO Principles

  • Single 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.

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

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

  • Design Patterns

  • Layered Architecture:Partition a complex program into layers.Ensure each layer is cohesive.

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

Development Approaches

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.


4 applying practices principles and patterns

4 Applying Practices, Principles, and Patterns

4.1 Our Development Approach

4.2 Project Plan

4.3 Iteration Plan

4.4 Repository Pattern

4.5 Value Object Pattern

4.6 Service Layer Pattern


4 1 our development approach

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 items

    • For 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 code

        • Run the tests

        • Add a little production code

        • Run the tests again

Document the result in a project plan.

Write the work items into an iteration plan.

TDD

steps

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

AMDD Development iteration steps

FDD practices


4 2 project plan

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 Fragment


4 3 iteration plan i1

4.3 Iteration Plan (I1)

Iteration I1. Adda new book to book repository

Iteration Workitems/Tasks

Tasks to be performed

in this iteration.

In which order?

Who should perform the task?


4 4 repository pattern

4.4 Repository Pattern

A respon-sible layer must be chosen.

e.g. Author

  • Context/Problem:

    • Some objects must be globally accessiblethrough 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 objectsbased on some criteria and return fully instantiated objects whose attribute values meet the criteria.

    • Repository objects encapsulate the actual storage and query technology.

Do not choose

ui, or app!!!

e.g. AuthorRepository, put in domain


4 4 repository pattern cont iteration 1 task tracking author instances

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

AuthorRepository class added to domain layer

Model storming

result

  • Model a bit ahead

    • Repository pattern applied

  • TDD Cycle 1: Add an author to the repository

    • Add author test case

      public 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 code

      private List<Author> authors;

      public AuthorRepository() {

      authors = new ArrayList<Author>();

      }

      public void add(Author author) {

      author.setId(authors.size()+1);

      authors.add(author);

      }

The model after

adding the test case

New methods

designed

Author.id

set by repository


4 4 repository pattern cont iteration 1 task tracking author instances cont

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

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

  • TDD Cycle 2: Find all authors

    • Find 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;

      }

      }

Don’t

forget

to call the base

class

method!

tearDown called after each testXxx() method is executed.

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!


4 4 repository pattern cont iteration 1 task tracking author instances cont1

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

  • TDD Cycle 2: Find all authors

    • Find 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”


4 4 repository pattern cont iteration 1 task tracking publisher instances

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.


4 5 value object pattern

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)


4 5 value object pattern cont iteration 1 task book specification class

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 specification

    • Add 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...


4 5 value object pattern cont iteration 1 task book class

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 specification

    • Add 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...


4 6 service layer pattern

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


4 6 service layer pattern cont iteration 1 task tracking book instances

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

Usually a service method uses several entity repositories (add, remove, and select operations).

Methods to be

designed

  • Model (Service Layer Pattern Applied)

Methods not shown


New tools for your ooad toolbox

New Tools for Your OOAD Toolbox

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

  • OO Principles

  • Single 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.

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

  • Design Patterns

  • Layered Architecture:Partition a complex program into layers.Ensure each layer is cohesive.

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

  • 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 Approaches

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.

Good software development usually

incorporates all of these development

models at different stages of the development

cycle.


Part ii agile model driven development

Part II: Agile Model Driven Development

Presents Agile Model Driven Development

project phases & iterations.

  • AMDD Lifecycle

  • Sample Application: Second Hand Store

  • Initial Modeling

  • Development Iterations

A more complex case study.

Several solutions will be

investigated during the next

courses.

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


Main references1

Main References


1 amdd lifecycle

1 AMDD Lifecycle

Presents activities performedwhen

a new system is developed.

1.1 Project View

1.2 General Agile System Development Lifecycle

1.3 Iteration 0: Initial Modeling

1.4 Iteration k: Development Iteration

Another perspective that shows

phases and iterations.

Presents subactivities or tasks

usually performed before starting

the development iterations.

Emphasizes on “model storming” activities

performed during development iterations.


1 1 project view

1.1 Project View


1 2 general agile system development lifecycle

1.2 General Agile System Development Lifecycle

AMDD Principle

AMDD

Activities


1 3 iteration 0 initial modeling

1.3 Iteration 0: Initial Modeling

Performed during the first week

of a project, or the first two

weeks for large projects.

  • 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:

      • Features, and

      • UML Use Cases.

    • Initial domain model, or conceptual model:

      • UML Class Diagrams

    • User interface model:

      • Screen Sketches

    • Initial architecture modeling

How users will

work with your

system.

Fundamental business entity

types and the relationships

between them.Your model

doesn’t need to be complete,

just to cover enough info to

make you comfortable with

domain business entities.

Identify an architecture

that has a good chance of working.

For UI

intensive projects.


1 4 iteration k development iteration

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

What operations should be provided

by the system in order

to fulfill use case scenarios.

How system objects collaborate to realize the system operations.

Include object operations into the current

design diagram.

Basic General Responsibility

Assignment Patterns that can

guide us to build a flexible design.


2 sample application second hand store shs

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:

      • Buy items together to save a given amount.

      • Free super saver shipping on orders over a given amount.


3 initial modeling

3 Initial Modeling

SHS - Iteration 0

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


3 1 usage models

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 List

      • Add new items to SHS repository.

      • Capture sales locally.

      • Make payments for sold items of a given client.

        ...

        Requirements List

      • Seller registers a contract for a client.

      • A contract includes many items.

      • The client and seller agree on the price for each item.

      • ...

Define one requirement at a time.

All these

req. corres-

ponds to

the first

feature.

Avoid conjunctions (and, or)

that make multiple requirements

Write a requirementas a

complete sentence, with a subject

and a predicate (usually a verb).

Subject is an actor, or a design entity.


3 1 usage models cont

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

System boundary

Use case

Actor


3 1 usage models cont1

3.1 Usage Models (cont)

  • 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

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

      • those that are deemed architecturally significant.


3 1 usage models cont2

3.1 Usage Models (cont)

  • How to detail use cases?

    • Use cases format

      • high-ceremony use cases - formal, highly structured

      • 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 items

    Customers 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


3 1 usage models cont3

3.1 Usage Models (cont)

High-ceremony (formal) format

Use case: Register contract

Description: Register a contract for a client

Actors: Seller

Preconditions: Seller is authenticated.

Postconditions: A new contract was created.

Normal flow

1. System shows the list of clients

2. Seller selects a client

3. System shows existing client’s contracts

4. Seller make a new contract

5. Seller enters a client item

This step may repeat.

6. Seller submit the contract

7. System registers submitted contract

8. A contract form is printed

Alternative Flows

2a. New client

1. Seller enters the new client information

*a. At any time, System fails

1. Seller retries to restart register contract

5a. 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

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, etc

Instead 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


3 2 initial domain model or conceptual model

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.

The model should be easily readable.

Even the stakeholder should be able to read it.

Acontract is signed byaclient.

Aclientmay havemanycontracts.

Business

transactions –

represent

the main

focus of

business

in the

SHS

domain

Capture

attributes if

the requirements

specify them.

Use labels on associations to make model readable.


3 3 initial architecture modeling

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.

Domain

objects

will remain

technically

indepen-

dent.

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.


3 4 project planning

3.4 Project Planning

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.

Iteration plan

(part of project plan)


Initial modeling summary

Initial Modeling Summary

Requirements express details of the features put in an appropriate format for developers.

  • Initial modeling tasks

    • Get features from the customers then build a requirements list

    • Create a use case model

    • Detail some use cases and scenarios

    • Define a conceptual model

    • Define the layering strategyfor the software architecture

    • Build an iteration plan

Usually

perfor-

med in this

order.

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.

Map requirements to development iterations.

A working logical architecture for the system.


4 development iterations

4 Development Iterations

Domain & App/Service

(barely good) models

AMDD development iteration steps

  • Model the current iteration scenarios or tasks

    • model services, and controllers

    • model entities, repositories

  • Write unit tests

  • Implement business logic

    • we return several times to write unit tests (according to TDD)

    • we also make model stormingsessions when necessary

  • Implement the front-end

Fix and improve the models by writing unit tests

Domain & service layers production

code

UI layer implementation


4 development iterations cont

4 Development Iterations (cont)

AMDD development iteration steps plus UML artifacts

4.1 Determine iteration tasks

  • A. Refine the domain model

  • B. Determine the system behavior

    • Write a system sequence diagram for each scenario

    • Write system operation contracts

  • C. Model controllers and services

  • D. Make a work item/task list

    4.2 Model then implement each work item

  • A. Establish object collaboration for each system operation

  • B. Model entities and repositories

  • C. Applying TDD

    • Write unit tests

    • Implement business logic

  • D. Implement the front-end

Include concepts related

to the current iteration


4 1 determine iteration tasks

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 session

      • try to make some investigations in order to understand what is needed to implement current iteration scenarios.

  • Iteration 1 Workitems/Tasks

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


4 1 a refine the domain model

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?

      • 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?

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


4 1 a refine the domain model cont

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 ofclients

    2. Seller selects a client

    3. System shows existing client’s contracts

    4. Seller make a new contract

    5. Seller enters a client item

    This step may repeat.

    6. Seller submit the contract

    7. System registers submitted contract

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


4 1 a refine the domain model cont1

4.1 – A. Refine the Domain Model (cont)

  • Apply UML roles and multiplicities.

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


4 1 b determine the system behavior

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.

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


4 1 b determine the system behavior cont

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.


4 1 b determine the system behavior cont1

4.1 – B. Determine the System Behavior (cont)

  • System Behavior for Register contract normal flow

System viewed as a black box

System event/user request

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

System must perform a computation to give...

a response.

That’s a system operation.


4 1 b determine the system behavior cont2

4.1 – B. Determine the System Behavior (cont)

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


4 1 b determine the system behavior cont3

4.1 – B. Determine the System Behavior (cont)

  • How to write system operation contracts?

    • Use the following template for system operation contracts:

      • Operation: Name of operation, and parameters

      • Description: What operation does.

      • Cross References: Use cases this operation can occur within

      • Preconditions: Assumptions about the state of the system or objects in the domain before execution of the operation.

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

    • To describe the post conditions, use the following categories:

      • instance creation and deletion

      • attribute modification

      • associations formed and broken


4 1 b determine the system behavior cont4

4.1 – B. Determine the System Behavior (cont)

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

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.

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

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


4 1 b determine the system behavior cont5

4.1 – B. Determine the System Behavior (cont)

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


4 1 c model controllers and services

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:

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

      • 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).


4 1 c model controllers and services cont

4.1 – C. Model Controllers and Services (cont)

  • Applying Controller and Service Layer Patterns

Programmer Y

Programmer X

Programmer Z


4 1 d make a work item task list

4.1 – D. Make a work item/task list

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.


4 1 determine iteration tasks summary

4.1 Determine Iteration Tasks Summary

Now the developers can work independently.

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

4.1 Determine iteration tasks

  • A. Refine the domain model

  • B. Determine the system behavior

    • Write a system sequence diagram for each scenario

    • Write system operation contracts

  • C. Model controllers and services

  • D. Make a work item/task list

    4.2 Model then implement each work item

  • A. Establish object collaboration for each system operation

  • B. Model entities and repositories

  • C. Applying TDD

    • Write unit tests

    • Implement business logic

  • D. Implement the front-end

Include concepts related

to the current iteration


4 2 model then implement each work item

4.2 Model, then Implement Each Work Item

  • A. Establish object collaboration for each system operation

  • B. Model entities and repositories

  • C. Applying TDD

    • Write unit tests

    • Implement business logic

  • D. Implement the front-end


4 2 a establish object collaboration cont

4.2 – A. Establish object collaboration (cont)

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

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

System operation assigned to controller objects

UI objects

Domain objects

Service

object

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

And, what about this one? NO.


4 2 a establish object collaboration cont1

4.2 – A. Establish object collaboration (cont)

  • GRASP: Information Expert

    • What 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.

Responsibility:

“a computation the system must perform”.

General Responsibility

Assignment Pattern


4 2 a establish object collaboration cont2

4.2 – A. Establish object collaboration (cont)

  • GRASP: Creator

    • Who 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):

      • B "contains" or compositely aggregates A.

      • B records A.

      • B closely uses A.

      • B has the initializing data for A.

  • Examples:

    Who creates an Item?

    • Contract – according to 1

    • ContractService – see 4

    • RegisterContractController – see 4

      Who creates a Contract?

    • SHStore – see 2

    • ContractService – see 3

    • RegisterContractController – see 4

But, which is better?

Are there any other advices?


4 2 a establish object collaboration cont3

4.2 – A. Establish object collaboration (cont)

  • GRASP: Low Coupling

    • How 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 to not create Items in these classes

Low coupling suggests that ContractService

and RegisterContractController should let

the Contract class to create Item instances in

order to minimize their dependencies.


4 2 a establish object collaboration cont4

4.2 – A. Establish object collaboration (cont)

  • GRASP: High Cohesion

    • How 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.


4 2 a establish object collaboration cont5

4.2 – A. Establish object collaboration (cont)

  • GRASP Pattern: Pure Fabrication

  • Problem: 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.


4 2 a establish object collaboration cont6

4.2 – A. Establish object collaboration (cont)

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


4 2 a establish object collaboration cont7

4.2 – A. Establish object collaboration (cont)

System Operation: getClients(): List<Client>

by Service Layer

by Repository

by Controller

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.

In a desktop app, frame instances call this op.

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

  • Moreover, the required visibilities between objects are:

  • ContractService must be visible to RegisterContractController.

  • ClientRepository must be visible to ContractService.


4 2 a establish object collaboration cont8

4.2 – A. Establish object collaboration (cont)

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

by Service Layer

by Repository

by Controller

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

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


4 2 a establish object collaboration cont9

4.2 – A. Establish object collaboration (cont)

This sequence diagram captures the remaining of system operations.

by Creator

by Controller

by Low Coupling, Indirection

by Creator

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

by Expert

by Repository

by Service Layer


4 2 b model entities and repositories

4.2 – B. Model entities and repositories


4 2 b model entities and repositories1

4.2 – B. Model entities and repositories


4 2 c applying tdd

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


4 2 c applying tdd1

4.2 – C. Applying TDD

Sequence Diagram


4 2 d implement the front end

4.2 – D. Implement the Front-End

Initialization and the 'Start Up' Use Case

  • When 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.


4 2 d implement the front end1

4.2 – D. Implement the Front-End

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


4 2 d implement the front end2

4.2 – D. Implement the Front-End

  • Guideline: Model-View Separation Principle

    • What 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).


4 2 d implement the front end3

4.2 – D. Implement the Front-End

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


4 2 d implement the front end4

4.2 – D. Implement the Front-End

  • Model-View-Controller Pattern

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

Classical

MVC

Show a

presentation

of the

model.

Usually

gets data

directly

from the

model.

1

  • Interactions

  • desktop ui:

  • 1,2, 4,5

  • web ui:

  • 1,2,3,5;

  • MVC

  • Model 2

3

2

4

5

Model send notifications of state changes to the views

Holds all data, state, and application logic


  • Login