OOAD Introduction 1-2. Agile Model Driven Development

1. OOAD Introduction1-2. Agile Model Driven Development Ioan Lazar

2. Table of Contents • Case Study: Second Hand Store • Development Approach: AMDD • It-0: Initial Modeling • It-1: Sign in

3. Main References

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

5. 2. Development Approach: AMDD • Agile Model Driven Development: http://www.agilemodeling.com/ • See also OpenUP: http://www.eclipse.org/epf/ Project View – presents activities performedwhen a new system is developed.

6. 3. It-0: Initial Modeling Performed during the first week of a project, or the first two weeks for large projects. 3.1 Usage Models • Features List • Requirements list • Use case Model 3.2 Initial Domain Model 3.3 Initial Architectural Modeling • Logical architecture 3.4 Project Planning • Plan iterations 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.

7. 3.1 Usage Models action resultobject • Feature list: • Contracts • Addnew items to SHS repository. • Updateprice and profit percentage for an existing item. • Makepaymentsfor sold items of a given client. • Showitems status of a given client. • Sales • Capturesales locally. • Sellitems 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. Feature: typically can be implemen- ted within a few hours Part of project vision Feature set Part of supporting requirements specification

8. 3.1 Usage Models (cont) Features are for customers, requirements are for developers... • Feature list: • Contracts • Addnew items to SHS repository. • ... • ... • 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. Avoid conjunctions (and, or) that make multiple requirements All these req. corres- ponds to the first feature. Write a requirementas a complete sentence, with a subject and a predicate (usually a verb). Subject is an actor, or a design entity.

9. 3.1 Usage Models (cont) Use Case Model A model of the system use cases and actors and the relationships between them. Use case: describes what your system does to accomplish a particular customer goal System boundary: shows the respon- sible subsystems Actor: something with behavior, such as a person (identified by role), computer system, or organization 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.

10. 3.1 Usage Models (cont) Detail some use cases and scenarios • 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. 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. Brief use case format • 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 high ceremony format, also called formal, highly structured. Use a low-ceremony use case format – informal, less rigidly structured; also called briefs.

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

12. 3.2 Initial Domain 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. Business transactions – represent the main focus of business in the SHS domain Acontract is signed byaclient. Aclientmay havemanycontracts. Capture attributes if the requirements specify them. Use labels on associations to make model readable.

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

14. 3.4 Project Planning The first iteration includes an entire use case while the second iteration includes a single scenario from another use case. Columns related to start and end dates omitted... Iteration plan (part of project plan)

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

16. 4 It-1: Sign In • Development iteration activities • An extract from logical architecture – relevant packages for iteration modeling. • We need to make • some analysis to • detail what is needed • to implement the • scenarios. Suppose the project team has four developers. Iteration 1 Work items/Tasks This is an entire use case What tasks dev elopers must do and which are their assignments?

17. 4.1 Iteration Modeling • Refine the domain model • Determine the system behavior • Write a system sequence diagram for each scenario • Write system operation contracts • Model controllers and services • Make a work item/task list StoreService.findSeller (username:String): Seller Return 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)

18. 4.1 Iteration Modeling (cont) Work item/task list Development iteration activities But, the relationships between service, domain, and infrastructure layers are not completely modeled. Model storming sessions... All developers can start taking the tasks with priority 1.

19. 4.2 Model Storming Mary must perform unit testing for StoreService, and she will configure the integration tests. John must perform unit testing for LoginContext. They settled thatStoreService and SellerRepository must be interfaces. Seller validation was not modeled; Ann needs this feature that will be made by George. Repository pattern applied for Seller instances.

20. 4.3 Test Driven Development 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. • Refactor functional and test code 1 2 3 4 Third, it’s a way to write clean code that works. TFD Steps

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

22. 4.3 TDD (cont)TDD Patterns • Test • How 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.

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

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

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

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

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

28. 4.5 Red Bar Patterns when you write tests, where you write tests, and when you stop writing tests • 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.

29. 4.5 Red Bar Patterns when you write tests, where you write tests, and when you stop writing tests • Another 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.

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

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

32. 4.7 Design Principles & Patterns • Program 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.

33. 4.7 Design Principles & Patterns • Open-Closed Principle • Classes 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.

34. 4.7 Design Principles & Patterns • Dependency Inversion Principle • Depend 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;

35. 4.7 Design Principles & Patterns • PoEAA 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.

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

37. 4.8 EasyMock Introduction • How to get a mock object? • Create a mock object for the interface you would like to simulate • I mock = (I) createMock(I.class); • Record the expected behavior expect(mock.f(2)).andReturn(4); expect(mock.g()).andThrow(new Exception(“Invalid ...”)); • 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); • ... • }

38. 4.9 Spring Introduction Spring IoC (Inversion of Control), Validation, Testing.

39. 4.9 Spring Introduction • Inversion 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();... Abstraction Dependent object This code is usually put in C. This design follows the dependency inversion principle. Collaborator object

40. 4.9 Spring Introduction • Inversion 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, and injects that object in the dependent object.

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

42. 4.9 Spring Introduction • Inversion 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)

43. 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();

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

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

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