software engineering 1 object-oriented analysis and design chap 24 iteration 2 more patterns

Software Engineering 1

Object-oriented Analysis and Design

Chap 24Iteration 2

More Patterns



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.

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.



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. 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.



Iteration-2 Requirements and Emphasis: Object Design and Patterns 1

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.

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)




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.




............

Senior15% off.

Preferred Customer10% off.

Each retailer uses different rules.Employee20% off.

Retailer policy.High.Purchaser discount rules. RULE4

SourceChangeabilityRuleID

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




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.

...




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.

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.

software engineering 1 object-oriented analysis and design chap 24 iteration 2 more patterns

Documents