CSC407: Software Architecture Summer 2006 ICONIX Revisited

1. CSC407: Software ArchitectureSummer 2006ICONIX Revisited Greg Wilson BA 3230 gvwilson@cs.utoronto.ca

2. Where We Just Were • ICONIX is a lightweight UML-based design process • Defines: • What diagrams you're supposed to produce • When • What questions they're supposed to answer • This lecture walks through it

3. GUI Prototype Sequence Diagram Roadmap Use Cases Robustness Diagram Domain Model Class Diagram Code

4. Step 1: Requirements • Identify real-world domain objects and the relationships between them • Prototype a GUI • Identify use cases • Milestone 1: requirements review

5. Step 2: Analysis • Write use cases • Perform robustness analysis • Identify objects used in each use case • Update domain model • Milestone 2: preliminary design review

6. Step 3: Design • Identify messages sent between objects • Finish turning domain model into class diagram • Add visibility, member variables, etc. • Decide relationship types • Milestone 3: detailed design review

7. Step 4: Delivery • Write unit tests • Write code • Perform integration testing • Milestone 4: deployment

8. Requirements Revisited GUI Prototype Use Cases • Sometimes called the "discovery" phase • Discover what the customer wants • Discover how the system wants to be built • Goal is to build a coherent vocabulary Domain Model

9. Grammatical Discovery • Simplest way to get started is grammatical discovery • Interview customer (or read email archive) • Nouns become objects, verbs become methods • Don't spend too much time in this phase • Even on a large project, a few days is plenty of time to evolve a problem-specific language that you can use for the rest of the work

10. What To Look For • Duplicate terms • Which objects interact directly with which • Which objects generalize which • Which objects "own" or "contain" which • Worry about multiplicity later • But make a note if a relationship has properties

11. Domain Modeling Errors • Don't assign multiplicities early • Dont' try to do use cases, domain modeling, and GUI prototyping independently • Don't worry about using generics, relational database tables, etc., at this stage • Don't try to impose design patterns

12. Sequence Diagram Analysis Revisited Use Cases Robustness Diagram • Bridge between analysis and design • What does each thing actually do? Domain Model

13. Purpose of Robustness Analysis • Sanity check on use cases • Completeness check: are all alternative cases accounted for? • Ongoing discovery of objects • Preliminary design

14. Three Types of Objects • Boundary objects are things that actors (e.g., users) interact with • Windows, dialogs, etc. • Entity objects are long-lived data • Typically mapped to database tables • Control objects contain the application's intelligence • Yes, this is Model-View-Controller…

15. Drawing Robustness Diagrams Allowed Boundary object Entity object Control object Not Allowed

16. Interaction Analysis • Robustness analysis told us which objects talk to which • Interaction analysis tells us what they say • Translate use cases into sequence diagrams • Translation can't be done directly if we don't know what objects we have

17. Sequence Diagram Format • Each sequence diagram should contain: • The text of the use case • Objects (use the robustness diagram icons) • Messages (arrows between lifelines) • Method names (labels on arrows) • Advanced tools can produce these semi-automatically

18. How To Tell If It's Right • Does it meet the first lecture's criteria? • Single Responsibility Principle • Liskov Substitution Principle • Law of Demeter • This is the time to use collaboration diagrams and state diagrams • If you're going to use them at all…

19. Sequence Diagram Classes and Code • After all this, the final design and coding are straightforward Domain Model Class Diagram Code

20. But What About Testing? • No well-known OO A&D methodology takes QA's needs into account • Which may be one of the reasons why there's still so much buggy code in the world • Have to design for test • Modularity • Well-defined specifications

21. How Do You Test This? PostgreSQL HTTP request Apache Python CGI Filesystem HTML

22. Naïve Strategy • Accept the system as given • Send HTTP, parse HTML • Faithful, but a lot of work PostgreSQL HTTP request Apache Python CGI Filesystem HTML

23. Record and Playback • Want to do regression testing to make sure we haven't broken anything while developing • Record a working system (HTTP in, HTML out) • Reply the HTTP, and diff the results

24. Pros and Cons • Allows non-programmers to create tests • But you have to have a nearly-working system before you start… • …and it's still screen-scraping • One small change to the GUI, and you have to re-record all your tests

25. Change the Problem • Don't look at HTML directly • Insert markers, and look for those <p> User ID: <em class="test" role="uid">GVW</em> </p> • Not checking everything • But insulated from minor changes in GUI • And you use CSS for styling anyway, right?

26. Faking the Server • How about getting rid of Apache? • Run the CGI directly • Have it generate XML instead of HTML • More productive, but less faithful PostgreSQL FakeCGI Python CGI Test Code Filesystem

27. Non-Persistent Persistence • Database is persistent storage • That's its whole purpose • But tests have to be independent • Re-creating the entire database for each unit test is painfully slow • Solution: move the database into memory • Two hours becomes three and a half minutes

28. Stubs and Mock Objects • Want to start testing before the whole system is ready • A stub is a placeholder that returns a neutral value (0, empty string, NULL, etc) • A mock object knows how to return something sensible in specific cases • Look up parameter values and pick a result

29. And Your Point Is…? • All of this is possible only if there are: • Clear boundaries • Clear semantics • They only happen if you design them in • Or spend a lot of time refactoring • Your QA department is your second most important user!