1. Mapping Designs to Code

2. It specify how to map the design into object oriented language The UML artifacts created during the design work, the interaction diagrams and Design Class Diagrams (DCDs) will be used as input to the code generation process. In UP there exists an Implementation Model. This is all the implementation artifacts, such as the source code, database definitions, JSP/XML/HTML pages, and etc. The creation of code in an OO language such as Java or C# is not part of OOA/D. It is an end goal

3. Mapping Designs to Code Implementation in an object-oriented language requires writing source code for: 1) Class and interface definitions 2) Method definitions 3) Collection Classes in Code

4. Mapping Designs to Code Creating Class Definitions from DCDs DCDs describe the class or interface name, superclasses, operation signatures, and attributes of a class. This is sufficient to create a basic class definition in an OO language.

5. Mapping Designs to Code Creating Class Definitions from DCDs From the DCD, a mapping to the attribute definitions and method signatures of SalesLineItem is straightforward, as shown

6. Mapping Designs to Code Creating Methods from Interaction Diagrams The sequence of the messages in an interaction diagram translates to a series of statements in the method definitions. The enterItem interaction diagram illustrates the Java definition of the enterItem method. For this example, we will explore the implementation of the Register and its enterItem method.

7. Mapping Designs to Code Creating Methods from Interaction Diagrams The enterItem message is sent to a Register instance; therefore, the enterItem method is defined in class Register.

8. Mapping Designs to Code Creating Methods from Interaction Diagrams The enterItem message is sent to a Register instance; therefore, the enterItem method is defined in class Register. public void enterItem(ItemID itemID, int qty) Message 1: A getProductDescription message is sent to the ProductCatalog to retrieve a ProductDescription. ProductDescription desc = catalog.getProductDescription(itemID); Message 2: The makeLineItem message is sent to the Sale. currentSale.makeLineItem(desc, qty);

9. Mapping Designs to Code Creating Methods from Interaction Diagrams The enterItem message is sent to a Register instance; therefore, the enterItem method is defined in class Register. public void enterItem(ItemID itemID, int qty) Message 1: A getProductDescription message is sent to the ProductCatalog to retrieve a ProductDescription. ProductDescription desc = catalog.getProductDescription(itemID); Message 2: The makeLineItem message is sent to the Sale. currentSale.makeLineItem(desc, qty);

10. Mapping Designs to Code Collection Classes in Code One-to-many relationships are common. For example, a Sale must maintain visibility to a group of many SalesLineItem instances, as shown in Figure In OO programming languages, these relationships are usually implemented with collection of object.

11. Mapping Designs to Code Collection Classes in Code For example, the Java libraries contain collection classes such as ArrayList. Using ArrayList, the Sale class can define an attribute that maintains an ordered list of SalesLineItem instances.

12. Test-Driven Development and Refactoring

13. Test-Driven Development (TDD) An excellent practice that applicable to the UP iterative methods is test-driven development (TDD) or test-first development. In this practice, unit testing code is written before the code to be tested, and the developer writes unit testing code for all production code.

14. Test-Driven Development (TDD) In OO unit testing TDD-style, test code is written before the class to be tested. The test is written first, imagining the code to be tested is written.

15. Test-Driven Development (TDD) Advantage The unit tests actually get written: Human nature is such that avoidance of writing unit tests is very common, if left as an afterthought.

16. Test-Driven Development (TDD) Advantage Programmer satisfaction leading to more consistent test writing: In the traditional style, a developer first writes the production code, informally debugs it, and then as an afterthought is expected to add unit tests, it doesn't feel satisfying. This is test-last development. However, if the test is written first, we feel a worthwhile challenge and question in front of us: Can I write code to pass this test? And then, after the code is cut to pass the tests, there is some feeling of accomplishment meeting a goal

17. Test-Driven Development (TDD) Advantage Clarification of detailed interface and behavior: Consider your state of mind if you write the test for an object first: As you write the test code, you must imagine that the object code exists. you must think through the details of the public view of the method, its name, return value, parameters, and behavior. That reflection improves or clarifies the detailed design.

18. Test-Driven Development (TDD) Advantage Provable, repeatable, automated verification: Obviously, having hundreds or thousands of unit tests that build up over the weeks provides some meaningful verification of correctness. And because they can be run automatically, it's easy. Writing tests starts to really feel like it's paying off as the size of the application grows.

19. Test-Driven Development (TDD) Advantage The confidence to change things: In TDD, there will eventually be hundreds or thousands of unit tests and a unit test class for each production class. Get confidence to change things

20. Test-Driven Development cycle (TDDC) Add a test: In test-driven development, each new feature begins with writing a test. To write a test, the developer must clearly understand the feature's specification and requirements. This may also be a modification of an existing test. This is a different feature of test-driven development versus writing unit tests after the code is written: it makes the developer focus on the requirements before writing the code

21. Test-Driven Development cycle (TDDC) Run all tests and see if the new one fails: This validates that the test is working correctly and that the new test does not mistakenly pass Write some code: The next step is to write some code that causes the test to pass. The new code written at this stage is not perfect. That is acceptable because later steps improve

22. Test-Driven Development cycle (TDDC) Run tests: If all test cases now pass, the programmer can be confident that the code meets all the tested requirements. Refactor code: Now the code should be cleaned up as necessary. Change the code for passing the test to where it logically belongs. Remove any duplication you can find. Make sure that variable and method names represent their current use.

23. Test-Driven Development cycle (TDDC) Repeat: Starting with another new test, the cycle is then repeated to push forward the functionality.

24. Refactoring Refactoring is a structured, disciplined method to rewrite or restructure existing code without changing its external behaviour, applying small transformation steps combined with re-executing tests each step.

25. Refactoring The essence of refactoring is applying small behaviour preserving transformations one at a time. After each transformation, the unit tests are re- executed to prove that the refactoring did not cause a regression (failure). Therefore, there's a relationship between refactoring and TDD. All those unit tests support the refactoring process.

26. Refactoring The activities and goals of refactoring include: remove duplicate code improve clarity make long methods shorter remove the use of hard-coded literal constants etc.

27. Refactoring Code that's been well-refactored is short, tight, clear, and without duplication. It looks like the work of a master programmer. Like patterns, refactorings have names that provide guidelines for a programmer to refactor the code better.