1 Software Development By Rick Mercer with help from these sources: Rational Unified Process Computing Fundamentals with C++, Rick Mercer Designing Object Oriented Software, Rebbeca Wirfs-Brock, Wilkerson, Wiener Object-Oriented Design Heuristics, Arthur Riel

2 Software Challenges  Specifications may be incomplete  Software product is expected to be used for a long time  Ever more complex systems, high expectations  Requirements change  We don't know what the customer wants  The customers don't know what they want

3 One Approach: Waterfall  Software go through several stages called the life cycle  Waterfall model

4 Waterfall Model

5 Waterfall Model (con.)  Waterfall has some severe problems. — The team has to be almost clairvoyant little room for error — places the high risk and difficult elements towards the end  Craig Larman's book[1] provides proof that waterfall has proved to be a terrible way to develop software.[1] — In a two-study, 87% of all investigated projects failed — The waterfall process was the "single largest contributing factor for failure, being cited in 82% of the projects as the number one problem." Rick will now attempt to tell a joke [1] Agile and Iterative Development: a Manager's Guide, Addison-Wesley Professional, 2003 [1]

6 Iterative Software Development  An iteration is a small part of the entire system

7 Rational Unified Process  Practices of RUP — Develop iteratively — Manage changing requirements — Use components such as Java classes — Visually Model with UML — Continuously test  RUP allows you to select from many processes

8 A Process we'll use  Agile Manifesto See  Started with Scrum and XP (Kent Beck’s eXtreme Programming), mid 1990s  Teams often choose from a set of practices  A few Agile practices we are or will be using — Planning game: stories, estimation, iterations — Test Driven Development (TDD) — Pair Programming — Continuous Integration — Sustainable Pace (determine velocity would be nice) — Coding Style (use the same style as team whether you like it or not) — On-site customer (simulated)

9 Responsibility Driven Design Responsibility Driven Design, Rebecca Wirfs Brock, 1990 The Coffee Machine Design Problem, Alistair Cockburn, C/C++ User's Journal, May and June Introducing Object-Oriented Design with Active Learning, Rick Mercer, Consortium for Computing in Small Colleges, 2000

10 In Rebecca Wirfs Brocks' Words Responsibility-Driven Design is a way to design that emphasizes behavioral modeling using objects, responsibilities and collaborations. In a responsibility-based model, objects play specific roles and occupy well-known positions in the application architecture. Each object is accountable for a specific portion of the work. They collaborate in clearly defined ways, contracting with each other to fulfill the larger goals of the application. By creating a "community of objects", assigning specific responsibilities to each, you build a collaborative model of our application. Responsible : able to answer for one's conduct and obligations—trustworthy, Merriam Webster

11 Responsibility Driven Design Summarizing Rebecca in Rick's words 1) Identify candidate objects that model a system as a sensible set of abstractions 2) Determine the responsibility of each object — what an instance of the class must be able to do, — and what each instance must know about itself 3) Understand the system through role play — To help complete its responsibility, an object often needs help from other objects

12 OO Design Principle The Single Responsibility Principle Classes should have a single responsibility  Why? — Cohesion, when high, reduces complexity, makes the system more understandable — Maintenance: Fixing or changing a module should not break other parts of the system

13 First Design a Model Note: design is iterative  Find a set of objects (candidate classes) that model a solution  Each will be a part of the bigger system  Each should have a single responsibility  What are these objects?

14 Find the Objects  Candidate objects may come from — The nouns in the problem statement Underline the noun phrases to look for the objects that could model the system — An understanding of the problem domain knowledge of the system that the problem specification may have missed or took for granted — The words floating around the room Alistair Cockburn