Chap 22 UML Tools and UML as Blueprint

1. Chap 22UML Tools and UML as Blueprint

2. Forward, Reverse, and Round-Trip Engineering Forward engineering the generation of code from diagrams; Reverse engineering generation of diagrams from code Round-trip engineering generation in either direction and can synchronize between UML diagrams and code, ideally automatically and immediately as either is changed.

3. Forward, Reverse, and Round-Trip Engineering All UML tools claim to support these features, but many are half crippled. code isn't just declarations of variables, it's dynamic behavior. If tool can generate a sequence diagram from the code, you can then much more easily follow the call-flow logic of the system to learn its basic collaborations.

4. Common Report of Valuable Features the most consistent report of UML tool value for reverse engineering, as a visualization learning aid to understand existing code. Generating UML package, class, and interaction diagrams from code and viewing the diagrams on a monitor, or printing them on large plotter paper, More UML tools become well-integrated with text-strong IDEs (Eclipse, Visual Studio..), and their usability improves more consistent value reported in using the tools for both forward and round-trip engineering.

5. Look For in a Tool Choosing a UML tool try a free UML tool. try it on a real project with as many developers as possible, before making a decision. Decide based on the guidance of your developers who have really used it for a long period.

6. Look For in a Tool Choosing a UML tool integrates into your favorite text-strong IDE. supports reverse engineering sequence diagrams from code. Choose a tool that supports printouts to a plotter, on large plotter paper, in large font and diagram sizes, so that large-scale visualization is possible.

7. Update the Diagrams After Coding If using a UML tool integrated with an IDE, working alone, and not doing wall sketching synchronizing the diagrams is a simple reverse-engineering operation in the IDE. If working with a small team and want to spend a modeling day each iteration at the whiteboards, applying UML as sketch. Consider this scenario: At the start of a three-week time boxed iteration, there was a modeling day involving UML wall sketches. This is followed by about three weeks of code and test. it's time to start the next iteration's modeling day.

8. Update the Diagrams After Coding if you wanted to do some wall sketching, based on the existing state of the code base. Just before the modeling day, use a UML tool to reverse engineer the code into UML diagrams, package, class, and interaction diagrams. for the most interesting ones, print them large on long plotter paper. Hang them relatively high in the modeling room on the walls during the modeling day, developers can refer to them, sketch on top of them, and sketch below them on whiteboards or static cling sheets.

9. Chap 23Quick Analysis Update

10. Case Study: NextGen POS Use Cases: No refinement is needed for the use cases this iteration. In UP, 1~2 day requirements workshop near the end of iteration-1 and the end of iteration-2 to investigate more requirements in detail. The previously analyzed use cases (e.g. Process Sale) will be revisited and refined based on insights gained from iteration-1 programming and tests. In iterative methods, early programming and testing with parallel requirements analysis improved by feedback from early development.

11. Case Study: NextGen POS SSDs This iteration includes adding support for third-party external systems with varying interfaces, such as a tax calculator. SSDs should be updated to reflect some of the inter-system collaborations.

12. Case Study: NextGen POS An SSD scenario that illustrates some external systems

13. Case Study: NextGen POS Domain Model In contrast to the prior iteration, the requirements being tackled this time do not involve many new domain concepts. A brief survey of the new requirements, like PriceRule as a domain concept. to skip refining the Domain Model, move quickly to design work, and let the discovery of new domain concepts occur during object design in the Design Model, when the developers are thinking through a solution, or indeed even while coding. Modeling can add value if one masters the basic guidelines of analysis and design, becomes comfortable with the "languages“ - use cases or UI prototypes.

14. Case Study: NextGen POS System Operation Contracts No new system operations are being considered in this iteration. In any event, contracts are only an option to consider when the detailed precision they offer is an improvement over the descriptions in the use cases.

15. Chap 24Iteration 2 More Patterns

16. From Iteration 1 to 2 When iteration-1 ends, the following should be accomplished: All the software has been tested: unit, acceptance, load, usability, and so on. The idea in the UP is to do early, realistic, and continuous verification of quality and correctness, so that early feedback guides the developers to adapt and improve the system.

17. From Iteration 1 to 2 When iteration-1 ends, the following should be accomplished: Customers have been regularly engaged in evaluating the partial system, to obtain feedback for adaptation and clarification of requirements. The system, across all subsystems, has been completely integrated and stabilized as a baselined internal release.

18. From Iteration 1 to 2 Some activities also be included An iteration planning meeting to decide what to work on in the next iteration, resolve questions, and identify major tasks. The start of the new iteration, use a UML tool to reverse engineer diagrams from the source code of the last iteration (the results are part of Design Model). to illustrate the starting point of the logical design for the next iteration. Usability analysis and engineering for the UI is underway. Database modeling and implementation is underway.

19. From Iteration 1 to 2 Some activities also be included Another two-day (for example) requirements workshop occurs, and more use cases are written in their fully dressed format. During elaboration, while perhaps 10% of the most risky requirements are being designed and implemented, there is a parallel activity to deeply explore and define perhaps 80% of the use cases for the system. Participants include developers/architect from the first iteration, so that the investigation and questioning during this workshop is informed from the insights gained from actually quickly building some software.

20. Iteration-2 Requirements and Emphasis: Object Design and Patterns For case studies iteration-2 ignores requirements analysis and domain analysis, and focuses on object design with responsibilities and GRASP, and applying some GoF design patterns.

21. Iteration-2 Requirements and Emphasis: Object Design and Patterns Iteration-2 of the NextGen POS application handles several interesting requirements: Support for variations in third-party external services. For example, different tax calculators must be connectable to the system, and each has a unique interface. Complex pricing rules. A design to refresh a GUI window when the sale total changes. These interesting requirements may be identified during inception. (e.g., the Process Sale use case indicates the pricing problem)

22. Iteration-2 Requirements and Emphasis: Object Design and Patterns Main Success Scenario of Process Sale use case : 1.Customer arrives at a POS checkout with goods and/or services to purchase. 2.Cashier tells System to create a new sale. 3.Cashier enters item identifier. 4.System records sale line item and presents item description, price, and running total. Price calculated from a set of price rules. ... Supplementary Specification record details of the domain rules for pricing, and indicate the need to support varying external systems.

23. Iteration-2 Requirements and Emphasis: Object Design and Patterns Supplementary Specification ... Interfaces Software Interfaces For most external collaborating systems (tax calculator, accounting, inventory, ... ) we need to be able to plug in varying systems and thus varying interfaces. ... Domain (Business) Rules

24. Iteration-2 Requirements and Emphasis: Object Design and Patterns Supplementary Specification Information in Domains of Interest Pricing In addition to the pricing rules described in the domain rules section, note that products have an original price, and optionally a permanent markdown price. A product's price (before further discounts) is the permanent markdown price, if present. Organizations maintain the original price even if there is a permanent markdown price, for accounting and tax reasons. ...

25. Iteration-2 Requirements and Emphasis: Object Design and Patterns Incremental Development for a Use Case Across Iterations Because of these requirements, we are revisiting the Process Sale use case in iteration-2, but implementing more scenarios. It is common to work on varying scenarios or features of the same use case over several iterations and gradually extend the system to ultimately handle all the functionality required.

26. Iteration-2 Requirements and Emphasis: Object Design and Patterns Incremental Development for a Use Case Across Iterations Short, simple use cases may be completely implemented within one iteration. One scenario should not be split across iterations; an iteration should complete one or more end-to-end scenarios. Iteration-1 made simplifications so that the problem and solution were not overly complex to explore.