Systems Analysis & Design Methods

1. Systems Analysis & Design Methods IX The development process: Adapted RUP (ARUP)

2. Why adapt RUP ? =The decision to use a RUP-dialect instead of plain RUP follows from these observations: • There are two related processes competing for attention RUP and XP: • RUP: Rational Unified Process (see article !) • Originally called Objectory and Rational Objectory Process • From the designers of UML, Booch, Jacobson & Rumbaugh • previously by owned by Rational, now owned by IBM, • eXtreme Programming (see article) • From Kent Beck IX The Process: Adapted RUP

3. Why adapt RUP ? • XP may not be suited for us: • XP seems a bit vague about what should happen prior to writing the first test case and writing the tested code. For the less experienced of us, it may be a good idea to be forced to make at least a sketch of a domain model, prior to coding. Granted, XP tells you, you should do all classic phases (Requirements, Analysis, Design, Testing) in every iteration. It is vague about what this Analysis & Design might be. IX The Process: Adapted RUP

4. Why adapt RUP ? • RUP may not be suited for us either: • It is simply too heavy, talks about too many models, and would take ages, just to learn what it is, let alone learn how to use it. IX The Process: Adapted RUP

5. What you will read about RUP & XP You will read: • XP is suitable, if both of the following conditions are true: • You have a small team (2-12) • Requirements are vague (users don’t know yet what they want) • RUP is suitable if one of the previous conditions are false. When using XP with large teams, the general (unspoken) idea that everyone needs to know everyone elses code details, becomes hard to defend, especially when requirements/specifications are clear. IX The Process: Adapted RUP

6. Adapted RUP: general idea • Use RUP skeleton • Remove less usefull techniques and diagrams • Replace construction phase with XP (no big deal: both are based on use cases and automated testing) • Add what I call ‘Robert C. Martin heuristics’ to help the design: -> uses case -> collaboration diagram -> class diagram -> improved class diagram (improved design) IX The Process: Adapted RUP

7. ARUP The text is based on Chapter 2 from UML Distilled (Martin Fowler, first edition 1997). The name RUP didn’t exist yet. It was called ‘The Rational Objectory Process’ at the time and it was still under construction. The chapter tried to summarize what ROP would become and it is without doubt, influenced by Fowlers own ideas. I will indicate whenever I add: • a personal comment (PC) • XP-elements (XP) • Robert C. Martin’s techniques • Martin Fowler’s advice IX The Process: Adapted RUP

8. Overview of the Software Development Process iterations 1 2 3 … Inception Elaboration Construction Transition IX The Process: Adapted RUP

9. Inception • Takes a few days. • Look at costs & gains. • Project scope & size (maybe do some analysis). • Sponsor may not have agreed yet. IX The Process: Adapted RUP

10. Elaboration • Takes one fifth of total length of the project. • Sponsor agrees • Only vague requirements -> Need better understanding of the problem: • Build what ? • Build how ? • Use what technology ? • The answers depend on the risks in the project: IX The Process: Adapted RUP

11. Elaboration: look at risks • Requirements risks • =danger of building the wrong system • -> Need to know requirements and its priorities • UML technique to use: • use cases. It is a UML diagram type, but text will do fine. • conceptual class diagram (a skeleton is fine) ‘=domain model’ • Technological risks • =danger of using technology that doesn’t work • E.g. you are going to use an OODB you hardly know : Ever tried it out ? (PC) • UML techniques to use: • Class diagram • Package diagram (dependencies between packages) • Deployment diagrams (big picture of used technologies) IX The Process: Adapted RUP

12. Elaboration: look at risks (continued) • Skills risk • Political risk • =danger that management will force awkward decisions. You must workt together with this consulting firm whose boss I play golf with (PC) IX The Process: Adapted RUP

13. Elaboration: Baseline Architecture • Baseline Architecture consists of: • list ofuse cases which tell you what the requirements are. These are a starting point for planning. • a domain model • To capture business understanding • Serves as starting point for domain classes • techology platform IX The Process: Adapted RUP

14. Elaboration: Planning • Planning: Planning is finished when you have: • Assigned use cases to iterations • Assigned start dates to iterations How does it work: • 1. Categorize use cases: • Users assign a priority level to each use case. • Developers assign a priority level to each use case based on architectural risk (design). • Developers assess their confidence in the time it takes to build the use cases. (schedule risk) IX The Process: Adapted RUP

15. Elaboration: Planning • 2. Determine iteration length (2 to 8 weeks): • Try and keep a fixed length for each iteration. • 3. Assign use cases to iterations: • Do not postpone high-risk use cases to the end IX The Process: Adapted RUP

16. Construction • Construction is done in iterations • Each iteration takes 2 to 8 weeks • Each iteration has several use cases • Each iteration is a mini-project in which you do analysis, design, coding, testing and integration. • The reason for doing iterations is to reduce risk. • Iterations are • Incrementalin function: each iteration, you add new functionality • Iterative in terms of the code base: each iteration, you will need to rewrite (refactor) exsiting code !!! IX The Process: Adapted RUP

17. Construction: testing • Some remarks about testing: • Write as much test code as production code (Kent Beck & Martin Fowler) • Before writing code you should know how to test it • XP: first write the test. • Test code should be kept and run forever • Test code should either say OK or give a list of failures • Split tests up into • Unit tests: written by developers, organized on package basis, test all class interfaces (=public methods ? PC) • System tests: black box tests, written by specialized testers • Integration: full integration at the end of each iteration: • XP: do full integration testing, much, much more frequently than that. IX The Process: Adapted RUP

18. Construction: refactoring • Software entropy and refactoring: • Entropy = the fact that in nature, structure and order often gradually disintegrate into chaos. The same thing can happen to software, after years of adding functionality. • When adding functionality, you should also redesign (refactor) the existing code. Fowler: ‘Scheduling pressure being what it is, most people prefer to put their pain off to the future’ • Fighting entropy: refactoring. Some Principles: • Do not refactor and add functionality at same time • Always provide good tests • Take short steps IX The Process: Adapted RUP

19. Construction: using the UML • You already have a conceptual level class diagram from the Elaboration phase • For the day to day work,I suggest(PC) you use Robert C. Martins techniques: -> uses case (but use just text) -> collaboration diagram -> class diagram -> improved class diagram (improved design) • Documentation (Martin Fowler): • Class diagram • Interaction diagrams (e.g. collaboration diagrams) • Some text to pull the diagrams together IX The Process: Adapted RUP

20. Construction: Remark about databases Traditionally, the OO community more or less ignores database issues. Simply stating that your business model should be independent of your data-model is not enough. So, I strongly suggest , that you also create normalized relational database design models (PC). IX The Process: Adapted RUP

21. Transition • Is the last phase • Typically between beta release and final release. • A thing to postpone to this phase is optimization. Why ? Optimization reduces clarity and extensibility: e.g. cashing inside functions, duplicating code to avoid procedure call time penalty (PC) IX The Process: Adapted RUP

22. Project assignments: Our solution • Group assignment (Exercise + Real) In general, you will use ARUP with databasemodels • Group work: • Elaboration phase: (Assigning uses cases to iterations and team members) • Extra: conclusion to the assesment of some tools (free and evaluation version) • Individual work: • Construction phase: Each team member will implement his use cases. No pair-programming, we will have code-ownership (practical reasons) I will play both the role of mentor and client. • Transition phase: Describe some ways you improved performance. • Extra: each team member will pick one case-tool to assess IX The Process: Adapted RUP

23. Project assignments: Remarks • More diagrams than really needed • You will create more diagrams than you normally would have to. • More case-tools than really needed • You will also draw more diagrams with tools than you would normally do. This is because I have to assess your ability to draw diagrams and your ability to learn and use tools. IX The Process: Adapted RUP

24. About Tools… Many views about tools exist: • Some say: • Create all models, exhaustive & detailed, preferabley in iterations. (class, sequence, … everything) • Either generate code from the models • Or handcode using the models as a blueprint. Carefully Keep model and code up to date. For them, tools are very important. The application is created with the tool. IX The Process: Adapted RUP

25. About Tools… • Others say: (Robert C. Martin) • Create some models • On the whiteboard, or with pencil & paper, just to communicate • When the team leaves (documentation, only high level) • Let your code express the design: make both high level and lower level code For them, tools are just cosmetics. The diagrams just look nicer when printed than wen drawn with a pencil. IX The Process: Adapted RUP

26. OO Modeling Tools • Links (right-click Open HyperLink) List of links to many download sites with OO modeling software • www.objectsbydesign.com/tools/umltools_byCompany.html Note: For most free modeling tools, you will need to download the latest version of the Java Runtime Environment. If you download JUST THAT, this takes only a minute or so. IX The Process: Adapted RUP

27. An OO case-tool case study: Argo UML: Class Diagram IX The Process: Adapted RUP

28. Argo UML: Remarks • Class Diagram Remarks: • Easy to learn • Code generation oriented: therefor: • Not possible: difference between conceptual, specification, implementation • Not possible: not specifiying attribute types • Not possible: NOT SPECIFIED navigatability I have to specify BIDIRECTIONAL to get rid of the navigatabilities • default property and association visibility is public ! IX The Process: Adapted RUP

29. A Database modeling Tool case study: Charonware Case studio • Charonware Case studio 2.15 lt. (30 days 6 entities) http://www.casestudio.com/enu/ddocument.aspx IX The Process: Adapted RUP

30. Charonware Case Studio: Remarks • ER Diagram Remarks: • +Easy to learn • +Supports different levels • High Level: no types, no (null/not null) ) • Physical Level: types, null/not null • -No support for generalization. (Some ER modeling techniques do allow it) • You have to fake it. IX The Process: Adapted RUP

31. Charonware Case Studio: ER diagram IX The Process: Adapted RUP