Level 3.1 CBT course on Design Models and OOAD

Slide 1: 

3/3/2011 TPG Confidential 1 Technology Practices Group Java Competency Framework "Incubate, Nurture and Deploy Technology Experts Innovate, Build and Deliver Technology Solutions”

Slide 2: 

3/3/2011 TPG Confidential 2 Introduction

Design Models & OOAD: Contents : 

3/3/2011 TPG Confidential 3 Design Models & OOAD: Contents Well Designed Application – using Object Orientation. Requirement Gathering & Use Cases. Requirements Change. Analysis OO Design Goals Good Design = Flexible Software Cohesion Solving really big problems Architecture Class Design Design Principles Iterating Testing OOA&D Lifecycle OOA&D Related Advice Case studies – Foreign Exchange system.

Well-Designed Application : 

3/3/2011 TPG Confidential 4 It takes very little for something to go wrong with an application that is fragile. You can use OO principles like encapsulation and delegation to build applications that are flexible. Encapsulation is breaking your application into logical parts. Delegation is giving another object the responsibility of handling a particular task. Always begin a project by figuring out what the customer wants. Well-Designed Application

Well-Designed Application (cont)… : 

3/3/2011 TPG Confidential 5 Well-Designed Application (cont)… Once you have got the basic functionality of an app in place, work on refining the design so it’s flexible. With a functional and flexible design, you can employ design patterns to improve your design further, and make your app easier to reuse. Find the parts of your application that changes often, and try and separate them from the parts of your application that don’t change. Building an application that works well but is poorly designed satisfies the customer but will leave you with pain, suffering, and lots of late nights fixing problems. Object oriented analysis and design (OOA&D) provides a way to produce well-designed applications that satisfy both the customer and the programmer.

Requirement Gathering & Use Cases : 

3/3/2011 TPG Confidential 6 Requirement Gathering & Use Cases Requirements are things your system muct do to work correctly. Your initial requirements usually come from your customer. To make sure you have a good set of requirements, you should develop use cases for your system. Use Cases detail exactly what your system should do. A use case has a single goal, but can have multiple paths to reach that goal.

Requirement Gathering & Use Cases (cont)… : 

3/3/2011 TPG Confidential 7 Requirement Gathering & Use Cases (cont)… A good use case has a starting and stopping conditions, an external initiator, and clear value to the user. After your use cases are complete, you can refine and add to your requirements. A requirements list that makes all your use cases possible is a good set of requirements. Your system must work in the real world, not just when everything goes as you expect it to. When things go wrong, your system must have alternate paths to reach the system’s goal.

Requirements Change : 

3/3/2011 TPG Confidential 8 Requirements Change Requirements will always change as a project progresses. When requirements change, your system has to evolve to handle new requirements. When your system needs to work in a new or different way, begin by updating your use case. A scenario is a single path through a use case, from start to finish. A single use case can have multiple scenarios, as long as each scenario has the same customer goal.

Requirements Change (cont)… : 

3/3/2011 TPG Confidential 9 Requirements Change (cont)… Alternate paths can be steps that occur only some of the time, or provide completely different paths through parts of a use case. If a step is optional in how a system works, or a step provides an alternate path through a system, use numbered sub-steps like 3.1, 4.1, and 5.1, or 2.1.1, 2.2.1, and 2.3.1. You should almost always try to avoid duplicate code. It’s a maintenance nightmare, and usually points to problems in how you’ve designed your system.

Analysis : 

3/3/2011 TPG Confidential 10 Analysis Analysis helps you ensure that your software works in the real world context, and not just in a perfect environment. Use cases are meant to be understood by you, your managers, your customers, and other programmers. You should write your use cases in whatever format makes them most usable to you and the other people who are looking at them. A good use case precisely lays out what a system does, but does not indicate how the system accomplishes that task. Each use case should focus on only one customer goal. If you have multiple goals, you will need to write multiple use cases.

Analysis (cont)… : 

3/3/2011 TPG Confidential 11 Analysis (cont)… Class diagrams give you an easy way to show your system and its code constructs at a 10,000-foot view. The attributes in a class diagram usually map to the member variables of your classes. The operations in a class diagram usually represent the methods of your classes. Class diagrams leave lots of details out, such as class constructors, some type information, and the purpose of operations on your classes. Textual analysis helps you translate a use case into code-level classes, attributes, and operations. The nouns of a use case are candidates for classes in your system, and the verbs are candidates for methods on your system’s classes.

Good Design = Flexible Software : 

3/3/2011 TPG Confidential 12 Good Design = Flexible Software Apply basic OO principles to add flexibility. By encapsulating what varies, you make your application more flexible, and easier to change. Whenever you find common behavior in two or more places, look to abstract that behavior into a class, and then reuse that behavior in the common classes. Coding to an interface, rather than to an implementation makes your software easier to extend. By coding to an interface, your code will work with all the interface’s subclasses – even one that haven’t been created yet.

Good Design = Flexible Software (cont)… : 

3/3/2011 TPG Confidential 13 Good Design = Flexible Software (cont)… When you have a set of properties that vary across your objects, use a collection, like a Map, to store those properties dynamically. You’ll remove lots of method from your classes, and avoid having to change your code when new properties are added to your app. Most good designs comes from analysis of bad designs – so, never be afraid to make mistakes and then change things around. Seeing how easy it is to change your software is one of the best ways to figure out if you really have well-designed software.

Cohesion : 

3/3/2011 TPG Confidential 14 Cohesion Cohesion measures the degree of connectivity among elements of a single module, class or object. The higher the cohesion of your software is, the more well-defined and related the responsibilities of each individual class in your application. A cohesive class does one thing really well and does not try to do or be something else.

Solving really big problems : 

3/3/2011 TPG Confidential 15 Solving really big problems The best way to look at a big problem is to view it as a collection of smaller problem. Just like in small projects, start working on big projects by gathering features and requirements. Features are usually “big” things that a system does, but also can be used interchangeably with the term “requirements”. Commonality and variability give you points of comparison between a new system and things you already know about. Use cases are detail-oriented; use case diagrams are focused more on the big picture.

Solving really big problems (cont)… : 

3/3/2011 TPG Confidential 16 Solving really big problems (cont)… Your use case diagram should account for all the features in your system. Domain analysis is representing a system in language that the customer will understand. An actor is anything that interacts with your system, but isn’t part of the system.

Architecture : 

3/3/2011 TPG Confidential 17 Architecture Architecture is the organizational structure of a system, including its decomposition into parts, their connectivity, interaction mechanisms, and the guiding principles and decisions that you use in the design of a system. The essence of a system is what that system is at its most basic level. Architecture helps you turn all your diagrams, plans, and feature lists into a well-ordered application. The feature in your system that are most important to the project are architecturally significant. Focus on features that are the essence of your system, that you’re unsure about the meaning of, or unclear about how to implement first.

Architecture (cont)… : 

3/3/2011 TPG Confidential 18 Architecture (cont)… Everything you do in the architectural stages of a project should reduce the risks of your project failing. If you don’t need all the detail of a use case, writing a scenario detailing how your software could be used can help you gather requirements quickly. When you’re not sure what a feature is, you should ask the customer, and then try and generalize the answers you get into a good understanding of the features. Use commonality analysis to build software solutions that are flexible. Customers are a lot more interested in software that does what they want, and comes in on time, than they are in code that you think is really cool.

OO Design Goals : 

3/3/2011 TPG Confidential 19 OO Design Goals Make software easier to change when we want to We might want to change a class or package to add new functionality, change business rules or improve the design We might have to change a class or package because of a change to another class or package it depends on (e.g., a change to a method signature) Manage dependencies between classes and packages of classes to minimize impact of change on other parts of the software Minimize reasons that modules or packages might be forced to change because of a change in a module or package it depends upon

OO Design (facts) : 

3/3/2011 TPG Confidential 20 OO Design (facts) Much of OO design is about managing dependencies It is very difficult to write OO code without creating a dependency on something => 99.9% of lines of code contain at least one significant design decision => Anyone who writes a line of code is defining the design be forced to change because of a change in a module or package it depends upon

Design Principles : 

3/3/2011 TPG Confidential 21 Design Principles Using proven OO design principles results in more maintainable, flexible, and extensible software. Principle 1: Open-Closed Principle (OCP) – classes should be open for extension, and closed for modification. Principle 2: Don’t Repeat Yourself (DRY) – Avoid duplicate code by abstracting out things that are common and placing those things in a single location. Principle 3: Single Responsibility Principle (SRP) – Every object in your system should have a single responsibility, and all the object’s services should be focused on carrying out that single responsibility. Principle 4: Liskov Substitution Principle (LSP) – Subtypes must be substitutable for their base types.

Class Design : 

3/3/2011 TPG Confidential 22 Class Design Class Cohesion Open-Closed Single Responsibility Interface Segregation Dependency Inversion Liskov Substitution Law of Demeter Reused Abstractions

Class Design: Class Cohesion : 

3/3/2011 TPG Confidential 23 Class Design: Class Cohesion Reasoning: Class design should reduce the need to edit multiple classes when making changes to application logic. A fundamental goal of OO design is to place the behavior (methods) as close to the data they operate on (attributes) as possible, so that changes are less likely to propagate across multiple classes

Class Design: Open-Closed : 

3/3/2011 TPG Confidential 24 Class Design: Open-Closed Reasoning: Once a class is tested and working, modifying its code can introduce new bugs. We avoid this by extending the class, leaving its code unchanged, to add new behavior. Classes should be open to extension, but closed to modification

Class Design:Single Responsibility : 

3/3/2011 TPG Confidential 25 Class Design:Single Responsibility Reasoning: Changing code in a tested class can introduce new bugs. We seek to minimize the reasons why a class might need to change. The more different things a class does, the more reasons it might have to change. Two reasons why this class might need to change changes to domain logic changes to XML format

Class Design: Interface Segregation : 

3/3/2011 TPG Confidential 26 Class Design: Interface Segregation Reasoning: If different clients depend on different methods of the same class, then a change to one method might require a recompile and redeployment of other clients who use different methods. Creating several client-specific interfaces, one for each type of client, with the methods that type of client requires, reduces this problem significantly.

Class Design:Dependency Inversion : 

3/3/2011 TPG Confidential 27 Class Design:Dependency Inversion Reasoning: Much of the duplication in code comes from client objects knowing about all sorts of specialized suppliers, that from the client's perspective do similar things but in different ways. Polymorphism is a powerful mechanism that underpins OO design. It allow s us to bind to an abstraction, and then w e don’t need to know what concrete classes we are collaborating with. This makes it much easier to plug in new components w ith no need to change the client code.

Class Design: Liskov Substitution : 

3/3/2011 TPG Confidential 28 Class Design: Liskov Substitution Reasoning: Dynamic polymorphism is a powerful mechanism that allows us to invert dependencies, reducing duplication and making change much easier. All OO design principles depend upon polymorphism, but we must ensure that any type can be substituted for any of its subtypes at run-time without having any adverse effect on the client. Subtypes must obey all of the rules that apply to their super-types - pre-conditions for calling methods, post-conditions of methods called, and invariants that always apply between method calls.

Class Design: Law of Diameters : 

3/3/2011 TPG Confidential 29 Class Design: Law of Diameters Reasoning: Objects should only collaborate with their nearest neighbors the less they depend on the interfaces of "friends of a friend", the less reasons they might have to have to change. This means avoiding long navigations and deferring knowledge of interactions with objects that aren't directly related to your nearest neighbors.

Class Design: Reused Abstraction. : 

3/3/2011 TPG Confidential 30 Class Design: Reused Abstraction. Reasoning: In test-driven development, abstractions are discovered by looking for similarities between classes or interfaces. Designers should distinguish between bone fide abstractions and indirection. A bone fide abstraction incorporates shared elements of two or more types into a single, shared abstraction to which both types conform. When we create arbitrary abstractions (e.g., interfaces for mock object tests), we create an extra maintenance burden with no pay off in term so removal of duplication. In simpler terms, abstractions should be extended or implemented by more than one class.

Design Principles (cont)… : 

3/3/2011 TPG Confidential 31 Design Principles (cont)… The Open-Closed Principle keeps your software reusable, but still flexible, but keeping classes open for extension, but closed for modification. With classes doing one single thing though the Single Responsibility Principle, it’s even easier to apply the OCP to your code. When you’re trying to determine if a method is the responsibility of a class, ask yourself, Is it this class’s job to do this particular thing? If not, move the method to another class. Once you have your OO code nearly complete, be sure that you Don’t Repeat Yourself. You’ll avoid duplicate code, and ensure that each behavior in your code is in a single place. DRY applies to requirements as well as your code: you should have each feature and requirement in your software implemented in a single place.

Design Principles (cont)… : 

3/3/2011 TPG Confidential 32 Design Principles (cont)… The Liskov Substitution Principle ensures that you use inheritance correctly, by requiring that subtypes be substitutable for their base types. When you find code that violates the LSP, consider using delegation, composition, or aggregation to use behavior from other classes without resorting to inheritance. If you need behavior from another class but don’t need to change or modify that behavior, you simple delegate to that class to use the desired behavior. Composition lets you choose a behavior from a family of behaviors, often via several implementations of an interface. When you use composition, the composing object owns the behaviors it uses, and they stop existing as soon as the composing object does.

Design Principles (cont)… : 

3/3/2011 TPG Confidential 33 Design Principles (cont)… Aggregation allows you to use behaviors from another class without limiting the lifetime of those behaviors. Aggregated behaviors continue to exist even after the aggregating object is destroyed.

Iterating : 

3/3/2011 TPG Confidential 34 Iterating The first step in writing good software is to make sure your application works like the customer expects and wants it to. Customers don’t usually care about diagrams and lists; they want to see your software actually do something. Use case driving development focuses on one scenario in a use case in your application at a time. In Use case driven development, you focus on a single scenario at a time, but you also usually code all the scenarios in a single use case before moving on to any other scenarios, in other use cases. Feature driven development allows you to code a complete feature before moving on to anything else.

Iterating (cont)… : 

3/3/2011 TPG Confidential 35 Iterating (cont)… You can choose to work on either big or small features in feature-driven development as long as you take each feature one at a time. Software development is always iterative. You look at the big picture, and then iterate down to a smaller pieces of functionality. You have to do analysis and design at each step of your development cycle, including when you start working on a new feature or use case.

Testing : 

3/3/2011 TPG Confidential 36 Testing Tests allow you to make sure your software doesn’t have any bugs, and let you prove to your customer that your software works. A good test case only tests one specific piece of functionality. Test cases may involve only one, or several, methods in a single class, or may involve multiple classes. Test driven development is based on the idea that you write your tests first, and then develop software that passes those tests. The result is fully functional, working software. Programming by contract assumes both sides in a transaction understand what actions generate what behavior, and will abide by that contract.

Testing (cont)… : 

3/3/2011 TPG Confidential 37 Testing (cont)… Methods usually return null or unchecked exceptions when errors occur in programming by contract environments. Defensive programming looks for things to go wrong, and tests extensively to avoid problem situations. Methods usually return “empty” objects or throw checked exceptions in defensive programming environments.

OOA&D Lifecycle : 

3/3/2011 TPG Confidential 38 OOA&D Lifecycle OOA&D Project Lifecycle: Feature List – Figure out what your app is supposed to do at a high level. Use Case Diagrams – Nail down the big processes that your app performs, and any external forces that are involved. Break Up the Problem – Break your application up into modules of functionality, and then decide on an order in which to tackle each of your modules.

OOA&D Lifecycle (cont)… : 

3/3/2011 TPG Confidential 39 OOA&D Lifecycle (cont)… Requirements – Figure out the individual requirements for each module, and make sure those fit in with the big picture. (iterative) Domain Analysis – Figure out how your use cases map to objects in your app, and make sure your customer is on the same page as you are. (iterative) Preliminary Design – Fill in details about your objects, define relationships between the objects, and apply principles and patterns. (iterative) Implementation – Write code, test it, and make sure it works. Do this for each behavior, each feature, each use case, each problem, until you’re done. (iterative) Delivery – Release your software.

OOA&D Related Advice : 

3/3/2011 TPG Confidential 40 OOA&D Related Advice IS-A and HAS-A: IS-A refers to inheritance, while HAS-A refers to composition or aggregation. Use inheritance when one object behaves like another, rather than just when the IS-A relationship applies. Use case formats – focus on interaction separating out what in a system, and how actors outside of the system interact with your software. Anti patterns are the reverse of design patterns: they are common BAD solutions to problems. These dangerous pitfalls should be recognized and avoided. Class, Responsibility, Collaborator (CRC) cards can help implement SRP Analysis.

OOA&D Related Advice (cont)... : 

3/3/2011 TPG Confidential 41 OOA&D Related Advice (cont)... Metrics can be helpful in pointing out strengths, weaknesses, and potential problems (e.g., Defect density and abstractness metric) You usually use software tools to take as input your class’s source code, and those tools then generate metrics based on your code and its design. (e.g., FindBugs) Use Sequence Diagrams to visually show the things that happen in a particular interaction between an actor and your system. Use State Diagrams to show complex behaviors visually. Unit Test your classes to ensure your application works when used by the customer. (e.g., use JUnit for Unit testing ).

OOA&D Related Advice (cont)... : 

3/3/2011 TPG Confidential 42 OOA&D Related Advice (cont)... Follow coding standard and write code that is readable – helps to maintain and reuse the code. Refactoring changes internal structure of your code without affecting your code’s behavior. Refactoring is done to increase the cleaness, flexibility, and extensibility of your code, and usually related to a specific improvement in your design.

Case Study: Foreign Exchange : 

3/3/2011 TPG Confidential 43 Case Study: Foreign Exchange The two case studies that follow are based on Foreign Exchange systems developed for a leading US bank. Foreign Exchange is the agreement between two parties to exchange one currency for another. The transaction or “trade” results in a shift of funds from one country to another. The Foreign Exchange operation has a J2EE based web-interface (FXW), and several Java based conformance utilities (like EDW).

Case Study 1: FX Rate Extract : 

3/3/2011 TPG Confidential 44 Case Study 1: FX Rate Extract Context: The FX Rate Extract is a relatively small Java utility that is run at end-of-day consolidating the Mark-to-Market exchange rates and sending it to an IBM-FTP server for processing.

Case Study 1: FX Rate Extract (cont)… : 

3/3/2011 TPG Confidential 45 Case Study 1: FX Rate Extract (cont)… We shall see how to solve this with OOA&D Lifecycle. Feature List: The application should consolidate rates on per trade type basis. The status of execution should be verifiable.

Case Study 1: FX Rate Extract (cont)… : 

3/3/2011 TPG Confidential 46 Case Study 1: FX Rate Extract (cont)… Use Case Diagram (produced using ArgoUML)

Case Study 1: FX Rate Extract (cont)… : 

3/3/2011 TPG Confidential 47 Case Study 1: FX Rate Extract (cont)… Break Up the Problem User (Front Office Trader) kicks off the Rate Extract Application. The Rate Extract connects and queries the database. The fetched data is consolidated for each trade category. The compiled data is formatted as required by the external interface, and written to a file. The output file is transferred through IBM-FTP. The status of the processing is stored for view by Back office Analyst.

Case Study 1: FX Rate Extract (cont)… : 

3/3/2011 TPG Confidential 48 Case Study 1: FX Rate Extract (cont)… Requirements The application should fetch exchange rates for each type of trade. The application should average rates for each trade type. The consolidated rates should be formatted as required by the external interface (another system which uses this as input). The compiled rates should be supplied as file to external system. The status of execution should be available for user to verify.

Case Study 1: FX Rate Extract (cont)… : 

3/3/2011 TPG Confidential 49 Case Study 1: FX Rate Extract (cont)… Domain Analysis Nouns: Trades, Exchange Rates, output file, log file. Verbs: fetch rates, average trade rates, format output, supplies a file.

Case Study 1: FX Rate Extract (cont)… : 

3/3/2011 TPG Confidential 50 Case Study 1: FX Rate Extract (cont)… Preliminary Design The class diagram shows two types of trades and the common Trade interface. A similar design for the extractor (not show) is developed before moving on to implementation.

Case Study 1: FX Rate Extract (cont)… : 

3/3/2011 TPG Confidential 51 Case Study 1: FX Rate Extract (cont)… Implementation The designed trade and extract types are coded. usually, the UML design tools (like ArgoUML) are capable of auto-generating the skeletal source code from design. Using JUnit, unit test cases are written and tested to ensure correctness of the functionality.

Case Study 1: FX Rate Extract (cont)… : 

3/3/2011 TPG Confidential 52 Case Study 1: FX Rate Extract (cont)… 8. Delivery – The fully tested Rate Extractor is added to Production. Note: For a complex feature rich application, the following steps will be iterated and tested: Requirements, Domain Analysis, Preliminary design and Implementation

Case Study 2: FXW Trade Entry : 

3/3/2011 TPG Confidential 53 Case Study 2: FXW Trade Entry Context: The FXW Trade Entry is a standard J2EE based web-application developed using Spring Framework. This application provides a nice web-interface for traders to enter the trade for online processing.

Case Study 2: FXW Trade Entry (cont)… : 

3/3/2011 TPG Confidential 54 Case Study 2: FXW Trade Entry (cont)… The Spring Framework’s core design principles, Dependency-Injection (DI) and Aspect-Oriented Programming (AOP) were suitable in reducing the complexity of the application. Spring Framework helps in developing applications with good OOA&D principles and guidelines. Typically, correctly developed Spring applications have high-cohesion & low-coupling.

Case Study 2: FXW Trade Entry (cont)… : 

3/3/2011 TPG Confidential 55 Case Study 2: FXW Trade Entry (cont)… DI follows the LSP design principle. It is strongly based on the guideline – Coding to an interface, rather than to an implementation makes your software easier to extend. New dependent classes, implementing the published interface, can be created and provided at run-time. Thus providing a much flexible design.

Case Study 2: FXW Trade Entry (cont)… : 

3/3/2011 TPG Confidential 56 Case Study 2: FXW Trade Entry (cont)… AOP is based on DRY design principle – which focuses on Separation of Concerns. Crosscutting concerns such as logging, security, transaction etc., are abstracted and kept common and applied as necessary.

Case Study 2: FXW Trade Entry (cont)… : 

3/3/2011 TPG Confidential 57 Case Study 2: FXW Trade Entry (cont)… Leveraging from Spring Framework’s DI and AOP, the FXW Trade Entry application can easily accommodate any new types of trades and exotic options. The business tier focuses on the core functionality of the system, leaving crosscutting concerns to be applied dynamically.