OOAD Introduction 1-2. Agile Model Driven Development

OOAD Introduction 1-2. Agile Model Driven

DevelopmentIoan Lazar

Table of Contents

1. Case Study: Second Hand Store2. Development Approach: AMDD3. It-0: Initial Modeling4. It-1: Sign in

Main References[Ambler07] Scott Ambler. Agile Modeling Home Page, 2007.

http://www.agilemodeling.com/

[Beck02] Kent Beck. Test-Driven Development by Example. Addison Wesley, 2002.

[EasyMock] EasyMock class library. http://www.easymock.org/

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

[Fowler02] Martin Fowler. Refactoring: Improving the Design of Existing Code. Addison Wesley, 2002.

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

[JUnit] JUnit Framework. http://www.junit.org/

[Nilsson06] Jimmy Nilsson. Applying Domain-Driven Design and Patterns: With Examples in C# and .NET. Addison Wesley, 2006.

[Spring] Spring Framework. http://www.springframework.org/

1. Case Study: Second Hand Store

• The owner of a small second hand store decided to throw out his paper-based system for keeping track of store items, and start using a computer based system to store its inventory.

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

• The required computer based system must also include: contract management, and sales/ payments management.

2. Development Approach: AMDD

• Agile Model Driven Development: http://www.agilemodeling.com/

• See also OpenUP: http://www.eclipse.org/epf/

Project View – presents activities performed when a new system is developed.

3. It-0: Initial Modeling

3.1 Usage Models– Features List– Requirements list– Use case Model

3.2 Initial Domain Model3.3 Initial Architectural Modeling

– Logical architecture3.4 Project Planning

– Plan iterations

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

architecture that has a good chance of working.

3.1 Usage Models• Feature list:

– Contracts• Add new items to SHS repository. • Update price and profit percentage for an existing item.• Make payments for sold items of a given client.• Show items status of a given client.

– Sales• Capture sales locally.• Sell items online.

• Business rules:– 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.

action result objectFeature:typically can be implemen-ted within a few hours

Feature set

Part ofprojectvision

Part of supporting requirements specification

3.1 Usage Models (cont)• Feature list:

• Contracts– Add new items to

SHS repository.– ...

• ...• Requirements List

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

Features are for customers,requirements are for developers...

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

3.1 Usage Models (cont)Use Case Model

Use case: describes what your system does to accomplish a particular customer goal

Actor:something with behavior, such as a person (identified by role), computer system, or organization

A model of the system use cases and actors and the relationships between them.

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.

System boundary:showsthe respon-siblesubsystems

3.1 Usage Models (cont)

Detail some use cases and scenarios

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

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.

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.Use a low-ceremony use case format –

informal, less rigidly structured; also called briefs.

Brief use case format

Use a high ceremony format, also called formal, highly structured.

3.1 Usage Models (cont)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) formatConditions 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

3.2 Initial Domain ModelDefine 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.

3.3 Initial Architecture Modeling• Logical architecture - the large-scale

organization of the software classes into packages (or namespaces), subsystems, and layers

• Layered architecture pattern [Fowler02]: (1,2), (3), (4,5,6), (7,8,9,10)

• Repository pattern [Evans04]: 6• Validation rules [Evans04]: 4• Transaction management at services

layer: Aggregate Pattern [Evans04], and Spring: 3, 6

• Configurable object validation: at ui, and/or service, and/or domain layer

3.4 Project Planning

Iteration Requirements (Use cases, scenarios)I1 Sign In

I2 Register contract – Normal Flow

I3 Register contract – Alternative flows

I4 Register sale

I5 Make payment

I6 Web sign inBrowse items

I7 Fulfill order

I8 View item status

Iteration plan(part of project plan)

Columns related to start and end dates omitted...

The first iteration includes an entire use case while the second iteration includes a single scenario from another use case.

It-0: 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.

4 It-1: Sign In

• Development iteration activities

Name/Description Priority State Assigned To

Sign in

...This is an entire use case

We need to make some analysis to detail what is needed to implement the scenarios.Iteration 1 Work items/Tasks

What tasks dev elopers must do and which are their assignments?

An extract from logical architecture – relevant packages for iteration modeling.

Suppose the project teamhas four developers.

4.1 Iteration Modeling1. Refine the domain model2. Determine the system behavior

a) Write a system sequence diagram for each scenario

b) Write system operation contracts

3. Model controllers and services4. Make a work item/task list StoreService.findSeller

(username:String): SellerReturn the seller having this username, if exists, or null, otherwise

LoginContext.login (username,password)Perform the authentication.Throws LoginException if the authentication fails.

2 b)

4.1 Iteration Modeling (cont)

Name/Description Priority Assigned To

Sign in

Main Application, Login Form, Login Controller, Logout Controller

2 John

Login Context 1 John

Store Service 1 Mary

Integration testing 2 Mary

Domain classes for Seller (including repository, and validation)

1 George

Infrastructure classes for file persistence

1 Ann

All developers can start taking the tasks with priority 1.

Work item/task list

But, the relationships between service, domain, and infrastructure layers are not completely modeled. Model storming sessions...

Development iteration activities

4.2 Model Storming

Repository pattern

applied for Seller instances.

They settled thatStoreService and SellerRepository must be interfaces.

Seller validation was not modeled; Ann needs this feature that will be made by George.

John must performunit testing forLoginContext.

Mary must performunit testing forStoreService, andshe will configure the integration tests.

4.3 Test Driven Development• 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.

5. Refactor functional and test code

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

4.3 TDD (cont)Different kinds of tests...

• Logic unit testing – These tests consider a single piece of functionality, often only a business method. – If a component is tested as a single unit, it’s tested independently from any other

component. Logic unit testing doesn’t involve any subsystems like databases.• Integration unit testing

– An integration test determines whether the interaction between software components, services, and subsystems works as expected.

• Functional unit testing– A functional test exercises a whole use case and the public interface in all

application components that are needed to complete this particular use case.• Acceptance testing

– the final stage of testing of a system, conducted by the customer (or any other party) who is deciding whether the system meets the project requirements.

• Performance testing– A stress or load test exercises the system with a high number of concurrent users,

ideally an equal or a higher load than is expected once the software runs in production.

4.3 TDD (cont) TDD Patterns

TestHow do you test your software? Write an automated test.

Isolated Test How should the running of tests affect one another? Not at all.

• the tests are order independent allows to run subsets of tests independently

• make the tests so fast to run that I can run them myself, and run them often

Test List What should you test? Before you begin, write a list of all the tests you know you will have to write.

4.3 TDD (cont) TDD Patterns

Test First When should you write your tests? Before you write the code that is to be tested.

Assert First When should you write the asserts? Try writing them first.

Test Data What data do you use for test-first tests? Use data that makes the tests easy to read and follow. You are writing tests to an audience.

Evident Data How do you represent the intent of the data? Include expected and actual results in the test itself, and try to make their relationship apparent. You are writing tests for a reader, not just the computer.

4.4 JUnit Patterns Assertion

How do you check that tests worked correctly? Write boolean expressions that automate your judgment about whether the code worked.

4.4 JUnit Patterns (cont)Test Method

How do you represent a single test case? As a method whose name begins with "test." Use also packages and classes to organize your tests.

Exception Test How do you test for expected exceptions? Catch expected exceptions and ignore them, failing only if the exception isn't thrown.

4.4 JUnit Patterns (cont)Fixture

How do you create common objects needed by several tests? Convert the local variables in the tests into instance variables. Override setUp() and initialize those variables.

External Fixture How do you release external resources in the fixture? Override tearDown() and release the resources.

4.4 JUnit Patterns (cont)All Tests

How do you run all tests together? Make a suite of all the suites—one for each package, and one aggregating the package tests for the whole application.

4.5 Red Bar Patterns One Step Test

Which test should you pick next from the list? Pick a test that will teach you something and that you are confident you can implement.

Starter Test Which test should you start with? Start by testing a variant of an operation that doesn't do anything.

Explanation Test How do you spread the use of automated testing? Ask for and give explanations in terms of tests.

Learning Test When do you write tests for externally produced software? Before the first time you are going to use a new facility in the package.

when you write tests, where you write tests, and when you stop writing tests

4.5 Red Bar PatternsAnother Test

How do you keep a technical discussion from straying off topic? When a tangential idea arises, add a test to the list and go back to the topic.

Regression Test What's the first thing you do when a defect is reported? Write the smallest possible test that fails and that, once run, will be repaired.

Break What do you do when you feel tired or stuck? Take a break.

Do Over What do you do when you are feeling lost? Throw away the code and start over.

Cheap Desk, Nice Chair What physical setup should you use for TDD? Get a really nice chair, skimping on the rest of the furniture if necessary.

when you write tests, where you write tests, and when you stop writing tests

4.6 Testing Patterns Child Test

How do you get a test case running that turns out to be too big? Write a smaller test case that represents the broken part of the bigger test case. Get the smaller test case running. Reintroduce the larger test case.

Mock Object How do you test an object that relies on an expensive or complicated resource? Create a fake version of the resource that answers constants.

Self Shunt How do you test that one object communicates correctly with another? Have the object under test communicate with the test case instead of with the object it expects.

4.6 Testing Patterns"Stubs: A class with methods that do nothing. They are simply there to allow the system to compile and run. Fakes: A class with methods that return a fixed value or values that can either be hardcoded or set programmatically. Mocks: A class in which you can set expectations regarding what methods are called, with which parameters, how often, etc. You can also set return values for various calling situations. A mock will also provide a way to verify that the expectations were met."

4.7 Design Principles & PatternsProgram to an Interface not an Implementation

“Program to an interface” really means “Program to a supertype”The point is to exploit polymorphism by programming to a supertype so that the actual runtime object is not locked into the code.The declared type of the variables should be a supertype (usually an abstract class or an interface), so that the object assigned to that variable could be of any concrete implementation of the supertype - which means the class that declare the variable does not known the actual implementation object types.The concrete implementations should be assigned at runtime.

4.7 Design Principles & Patterns

Open-Closed PrincipleClasses should be open for extension, but closed for modification.

• Allow classes to be easily extended to incorporate new behavior without modifying existing code.

• The result? Designs that are resilient to change and flexible enough to take on new functionality to meet changing requirements.

4.7 Design Principles & Patterns

Dependency Inversion PrincipleDepend upon abstractions. Do not depend upon concrete classes.

• At first, this principle sounds like Program to an interface not an implementation.

• But this principle makes an even stronger statement about abstraction. It suggests that:– high-level components should not depend on low-

level components;– rather, they should both depend on abstractions;

4.7 Design Principles & PatternsPoEAA Separated Interface (Fowler, 2002)Define an interface in a separate package from its implementation.You use Separated Interface when you need to break a dependency between two parts of the system. Here are some examples:– You've built some abstract code for common cases into a

framework package that needs to call some particular application code.

– You have some code in one layer that needs to call code in another layer that it shouldn't see, such as domain code calling the infrastructure layer.

– You need to call functions developed by another development group but don't want a dependency into their APIs.

4.8 EasyMock Introduction• Suppose we have the

following model:– we need to implement C

that uses an I (the method m first call f, and then g).

– how can we test C?• IImpl may not

be available, or• IImpl may be

expensive to create.– In order to test C in

isolation (unit tests for C) we need a “mock” implementation for I.

4.8 EasyMock Introduction• How to get a mock object?1. Create a mock object for the interface

you would like to simulate• I mock = (I) createMock(I.class);

2. Record the expected behaviorexpect(mock.f(2)).andReturn(4);

expect(mock.g()).andThrow(new Exception(“Invalid ...”));

3. Switch the mock object to replay state.• replay(mock);

• Using a mock object• CTest.testM() {• //Put here the code from 1, 2, and 3• C c = new C();• c.setI(mock);• c.m(); // f, and g called• verify(mock);• ...• }

4.9 Spring Introduction

Spring IoC (Inversion of Control),Validation, Testing.

4.9 Spring IntroductionInversion of Control (IoC) Principle Suppose we have a component that uses another component that implements a given interface. How the component could obtain a plugin implementation?Dependency Lookup. Usea factory bean to lookupfor the collaborator, such as:

I i = factoryBean.getBean(“i”);i.f();...

Collaborator object

Dependent object

Abstraction

This design followsthe dependency inversion principle.

This codeis usually put in C.

4.9 Spring IntroductionInversion of Control (IoC) Principle Suppose we have a Component that uses another component that implements a given Interface. How the component could obtain a plugin implementation?Dependency Injection. Usean assembler object that injects (populates) a field in the dependent object.

Based on a config,finds an appropriate implementation, creates a collaborator, andinjects that object in the dependent object.

4.9 Spring Introduction

Inversion of Control (IoC) Principle Constructor Injection. The Assembler uses the constructor to inject or setthe implementation.

Assembler proceeds as follows:

I i = new IImpl();C c = new C(i);

4.9 Spring IntroductionInversion of Control (IoC) Principle Setter Injection. The Assembler uses a setter method to inject or setthe implementation.

Assembler proceeds as follows:

I i = new IImpl();C c = new C();c.setI(i)

4.9 Spring Introduction• <?xml version="1.0" encoding="UTF-8"?>

• <beans xmlns=“...">• <bean id=“cBean"

class=“C"> <property name=“i"

ref=“iBean" /></bean><bean id=“iBean"

class=“IImpl"></bean>

• </beans>

public class C {

private I i;

public void setI(I i) { this.i = i;}

public void fun() {i.f();} }

FileSystemXmlApplicationContext factory = new FileSystemXmlApplicationContext("classpath:conf/spring-config.xml");

C c = (C) factory.getBean(“cBean");c.fun();

4.10 Integration Testing Using Spring

• public class CIntegrationTest extends AbstractDependencyInjectionSpringContextTests {

private C c;

public void setC(C c) {this.c = c;

}public void testC() throws Exception { ...}

protected String[] getConfigLocations() {return new String[] { "classpath:conf/spring-config.xml" };

}

protected onSetUp() { ... }• }

This instance will be (automatically) dependency injected.

A setter method to enable DI of the ‘i' instance variable.

Specifies the Spring configuration to load for this fixture.

Add more objects to the fixture by overriding the template method onSetUp().

4.11 Refactoring• Refactoring (noun): a change made to the

internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior.

• Refactor (verb): to restructure software by applying a series of refactorings without changing its observable behavior

• Why Should You Refactor?– Refactoring improves the design of software – Refactoring makes software easier to understand

4.11 Refactoring• When should you refactor?

– Refactor when you add function– Refactor when you need to fix a bug– Refactor as you do a code review

• Bad smells in code – Duplicated Code – Long Method – Large Class – Long Parameter List – Switch Statements

• If you want to refactor, the essential precondition is having solid tests. Even if you are fortunate enough to have a tool that can automate the refactorings, you still need tests.