ooad introduction 1-2. agile model driven development
DESCRIPTION
OOAD Introduction 1-2. Agile Model Driven Development. Ioan Lazar. Table of Contents. Case Study: Second Hand Store Development Approach: AMDD It-0: Initial Modeling It-1: Sign in. Main References. 1. Case Study: Second Hand Store. - PowerPoint PPT PresentationTRANSCRIPT
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.