|
|
 |
| Авторизация |
|
|
|
| Поиск по указателям |
|
|
|
|
|
|
|
 |
|
|
|
| Rosenberg D., Stephens M. — Use Case Driven Object Modeling with UML: Theory and Practice |
|
|
|
| Предметный указатель |
AbstractCommandController class 274
Acceptance testing 333
Acegi Security 179
Actors as external to the system 54
Actors as fulfilling several roles 54
Actors, adding a Customer actor to a robustness diagram 117
Actors, modeling external systems as 35
Actors, placing on use case diagrams 32
Actors, representing nonhuman external systems 54
Actors, roles of, in use case diagrams 53
Add External Books to Catalog use case 128 218
Adding operations to domain objects 4
addToPendingReviewsQueue() 284
AddToShoppingCartTest test case 340
Advices 74
Aggregation (has-a) relationship 24 27 33
Algorithms, differentiating from use cases 76
Alternate courses, displaying in a different color on robustness diagrams 110
Alternate courses, Login use case, example robustness diagram 110
Alternate courses, modeling in a robustness diagram 122
Analysis and preliminary design phase 3 9
Analysis paralysis 175
Anemic domain model 242
Architectural layering, architectural diagrams, examples of 162
Architectural layering, definition of 162
Architectural layering, horizontal vs. vertical layers 163
Architectural layering, UML class diagrams 164
Architectural paralysis 180
Arrows as communication associations on robustness diagrams 108
Arrows, showing data flow or control flow 108
aspect-oriented programming (AOP) 74
Aspect-oriented programming (AOP) as extending object-oriented programming (OOP) 171
Aspect-oriented programming (AOP), defining cross-cutting concerns through code 171
Aspect-oriented programming (AOP), problems with 172
Assert methods, in JUnit 339
AssertEquals(), arguments used 340
Attributes, discordant 205
Avoiding dysfunctional requirements 6
Beck, Kent 351
Behavioral requirements 3—4 7
Beizer, Boris 334
beta testing 333
BillyBob 2.0, requirements for 379
Book class as an unused object on a sequence diagram 246
Book class, distribution of responsibilities in 238
Book.java, code example 266
BookDao 243 255
Bookdetails.jsp 274 277
BookDetailsCommand 240
BookDetailsController 240 243 272—273 275 305 359—360 362
Bookstore-servlet.xml 287 290 315 419—421
Bookstore.css 265
Boundary objects 8 187
Boundary objects, definition of 103
Boundary objects, disambiguated nomenclature of 108
Boundary objects, referencing by name in use cases 52 61
Boundary objects, treating as nouns 103
Building a project glossary 7
callTestHandle() 365
Carnegie Mellon Software Engineering Institute 161
CASE tools 57 105 193 203 260
CDR guidelines 15
checkBookFound() 358
checkRating() 319
checkReviewLength() 318
checkTitleLength() 318
Class attributes, relationship to database tables 29
class diagrams 4
Class diagrams, adding getters and setters to 211
Class diagrams, conventions of 164
Class diagrams, domain model and 24 28—29
Class diagrams, finishing the updating of 127
Class diagrams, keeping static and dynamic models in sync 211
Class diagrams, tidying up for a clearer layout 255
Class diagrams, updating and refining 210
Class diagrams, using to find errors on sequence diagrams 238
Class notation, types of 27
Classes, allocating behavior to 188
Classes, assigning operations to 125
Classes, distribution of responsibilities among 239
Classes, organizing around key abstractions in the problem domain 28
Classes, relationship to use cases 51
Classes, searching for classes without attributes 236
Classes, subclasses and superclasses 37
Cleaning up the static model 14
Code Review and Model Update guidelines 18
Code Review and Model Update, accumulating boilerplate checklists for future reviews 299—300
Code Review and Model Update, avoiding review and update paralysis 299 301
Code Review and Model Update, breaking down list items into a smaller checklist 299
Code Review and Model Update, catching design or integration issues early 298
Code Review and Model Update, code review vs. code inspection 302
Code Review and Model Update, comparing the code with the design diagrams 298
Code Review and Model Update, conducting a productive code review 301
Code Review and Model Update, creating a high-level list of review items (use case titles) 299
Code Review and Model Update, emailing action points to all participants 299—300
Code Review and Model Update, focusing on error detection, not error correction 299—300
Code Review and Model Update, frequency of 298
Code Review and Model Update, guidelines 299
Code Review and Model Update, keeping the review just formal enough 299 301
Code Review and Model Update, not forgetting the Model Update session 299 301
Code Review and Model Update, preparing for 299
Code Review and Model Update, purpose of 298
Code Review and Model Update, quickly addressing disparities between code and design 303
Code Review and Model Update, reusing objects in the domain model 298
Code Review and Model Update, reviewing code at different levels 299—300
Code Review and Model Update, syncing code with design 297
Code Review and Model Update, updating and refining the static model 298
Code Review and Model Update, using an integrated code/model browser 299 301
Code Review and Model Update, value of up-front design 303
Code Review and Model Update, why code reviews are necessary 302—303
Coding and testing 4 15
Collaboration diagrams, function of 109
Collaboration diagrams, not confusing with robustness diagrams 107—108
Collaboration diagrams, purpose of 107
Command objects, definition of 168
Commenting code 259 262
compatibility testing 333
Constructor Injection 412
Controller interface 412
Controller objects, lack of, on sequence diagrams 187
Controller objects, using sparingly 108
controllers 3 11 412
Controllers as logical software functions 11
Controllers as methods on the boundary and entity classes 109
Controllers as real control objects 11
Controllers, creating test cases for 109
Controllers, definition of 103
Controllers, ensuring proper test coverage for 350
Controllers, names of 120
Controllers, renaming those with the same name on a diagram 345
Controllers, running test cases for data-retrieval controllers 356
Controllers, Show Book Details use case 351
Controllers, treating as verbs 103
Create New Book use case 219
Create New Customer Account use case 128
Critical Design Review (CDR) 4 15
Critical Design Review (CDR), allocating operations to classes appropriately 235—236
Critical Design Review (CDR), centralizing responsibility in a class 240
Critical Design Review (CDR), checking for continuity of messages 234
Critical Design Review (CDR), checking for entity classes without attributes 251
Critical Design Review (CDR), checking that operations are complete and correct 235 237
Critical Design Review (CDR), coupling object-oriented encapsulation with RDD 239
Critical Design Review (CDR), covering both basic and alternate courses of action 235—236
Critical Design Review (CDR), determining if the sequence diagram matches the class diagram 250
Critical Design Review (CDR), discovering unexplored areas in the analysis space 251
Critical Design Review (CDR), distribution of responsibilities in the Book class 238
Critical Design Review (CDR), ensuring that the sequence diagram matches the use case text 234—236
Critical Design Review (CDR), generating and inspecting the code headers for classes 235 237
Critical Design Review (CDR), generating skeleton tests from the robustness diagram 238
Critical Design Review (CDR), guidelines 235
| Critical Design Review (CDR), having all patterns reflected on the sequence diagram 235 237
Critical Design Review (CDR), identifying a stable set of abstractions 249
Critical Design Review (CDR), identifying attributes from functional requirements 251
Critical Design Review (CDR), ironing out leaps of logic between objects 234
Critical Design Review (CDR), limiting to designers and developers, not customers 234
Critical Design Review (CDR), minimizing code breakage and refactoring 249
Critical Design Review (CDR), performing a sanity check on the design 235 237
Critical Design Review (CDR), primary goals 234
Critical Design Review (CDR), reviewing the attributes and operations on classes 235—236
Critical Design Review (CDR), reviewing the quality of the design 234
Critical Design Review (CDR), reviewing the test plan for the release 235 237
Critical Design Review (CDR), searching for classes without attributes 236
Critical Design Review (CDR), setting the starting time for 235
Critical Design Review (CDR), Show Book Details use case 238
Critical Design Review (CDR), tracing functional requirements to use cases and classes 235 237
Critical Design Review (CDR), using class diagrams to find errors on sequence diagrams 238
Critical Design Review (CDR), Write Customer Review use case 245
Cross-cutting concerns, extension use cases 74
Cross-cutting concerns, infrastructure use cases 74
Cross-cutting concerns, peer use cases 74
CustomerReview 247 311
CustomerReviewValidator class 311
CustomerSession class 179 287
Data Access Objects (DAOs) 165 169—170 175
Data analysis and reduction, definition of 378
Data capture, definition of 378
Data Definition Language (DDL) 259
Data model 161
Data reporting, definition of 378
Database tables, relationship to class attributes 29
Dependency Injection (DI) 409 412
Deployment model 161 173 175
Design as building the system right 9
Design-Driven Testing (DDT), acceptance testing 333
Design-Driven Testing (DDT), adding a tearDown() method 350
Design-Driven Testing (DDT), AddToShoppingCartTest test case 340
Design-Driven Testing (DDT), adopting a testing mind-set 330
Design-Driven Testing (DDT), aligning tests closely to requirements 331
Design-Driven Testing (DDT), avoiding duplicating alternate course scenarios 369
Design-Driven Testing (DDT), avoiding duplication in tests 343
Design-Driven Testing (DDT), beginning testing before coding 369
Design-Driven Testing (DDT), beta testing 333
Design-Driven Testing (DDT), compatibility testing 333
Design-Driven Testing (DDT), covering basic and alternate courses in scenario testing 331
Design-Driven Testing (DDT), creating a resource in the test method itself 349
Design-Driven Testing (DDT), creating unit tests for each controller on a robustness diagram 330
Design-Driven Testing (DDT), DDT errors, list of 369
Design-Driven Testing (DDT), different types of testing 330
Design-Driven Testing (DDT), discovering alternate courses during 338
Design-Driven Testing (DDT), doing requirement-level verification 331
Design-Driven Testing (DDT), doing scenario-level acceptance testing 331
Design-Driven Testing (DDT), driving unit tests from test cases 338
Design-Driven Testing (DDT), driving unit tests from use cases 330
Design-Driven Testing (DDT), ensuring that each test method tests exactly one thing 342
Design-Driven Testing (DDT), finding and fixing buggy code 370
Design-Driven Testing (DDT), function of 329
Design-Driven Testing (DDT), generating test skeleton code for unit testing 334
Design-Driven Testing (DDT), guidelines 330
Design-Driven Testing (DDT), identifying and targeting “test hot spots” 370
Design-Driven Testing (DDT), identifying test cases using robustness diagrams 329 334
Design-Driven Testing (DDT), identifying the test scenarios for each controller/test case 335
Design-Driven Testing (DDT), integration testing 333
Design-Driven Testing (DDT), keeping unit tests fine-grained 331 342
Design-Driven Testing (DDT), linking one test case to each controller 336
Design-Driven Testing (DDT), mapping test cases directly to JUnit test classes 339
Design-Driven Testing (DDT), mock objects, testing with 354
Design-Driven Testing (DDT), neglecting to fix a failing test 343
Design-Driven Testing (DDT), nonfunctional requirements testing 333
Design-Driven Testing (DDT), not writing tests that connect to external resources 353
Design-Driven Testing (DDT), performance testing 334
Design-Driven Testing (DDT), practice questions to test your knowledge 370—371
Design-Driven Testing (DDT), preparing for, during the analysis stage 329
Design-Driven Testing (DDT), programmers’ attitudes toward 331
Design-Driven Testing (DDT), proving a test by trying to make it fail 348
Design-Driven Testing (DDT), regression testing 334
Design-Driven Testing (DDT), release testing 333
Design-Driven Testing (DDT), running tests from a test suite 350
Design-Driven Testing (DDT), stress testing 334
Design-Driven Testing (DDT), system testing 333
Design-Driven Testing (DDT), testing paralysis 370
Design-Driven Testing (DDT), transforming a robustness diagram into a test case diagram 334
Design-Driven Testing (DDT), treating unit test code with reverence 342
Design-Driven Testing (DDT), tying closely to requirements 329
Design-Driven Testing (DDT), tying unit tests to the preliminary design objects 342
Design-Driven Testing (DDT), understanding the tests required at each life cycle stage 331
Design-Driven Testing (DDT), unit test skeletons, guidelines for creating 338
Design-Driven Testing (DDT), unit testing 332
Design-Driven Testing (DDT), using a testing framework 331
Design-Driven Testing (DDT), using a traceability matrix 331
Design-Driven Testing (DDT), using mock objects sparingly 343 369
Design-Driven Testing (DDT), using the Agile ICONIX/EA add-in to generate diagrams 336
Design-Driven Testing (DDT), using “realize” connectors 334
Design-Driven Testing (DDT), volume testing 334
Design-Driven Testing (DDT), why bother with designing unit tests 366
Design-Driven Testing (DDT), writing effective unit tests 342—343
Design-Driven Testing (DDT), writing tests from the calling object’s point of view 338 347 358
Design-Driven Testing (DDT), writing tests to validate and hone the design 369
Detailed design phase 3 12 186
Discordant attributes 205
DispatcherServlet 167 174—176 178 269 271 306 347 415—416 419
Display Book Not Found page controller 345
Display controllers, initialization behavior and 111
Display controllers, necessity for, on robustness diagrams 111
DisplayBookDetailsPageTest 365
doesBookIDExist() 247
Domain classes 7 24 27 30
Domain classes, candidates for the Internet Bookstore 33
Domain classes, referencing by name in use cases 52 59
Domain model 11
Domain model diagrams, creating 33 35
Domain model diagrams, ensuring coverage of the problem domain 85
Domain model diagrams, showing generalization and aggregation relationships 86
Domain model diagrams, using a link class 86
Domain model, assumed to be incomplete 28
Domain model, class diagrams and 24 28—29
Domain model, creating before use cases 29
Domain model, definition of 24
Domain model, deliberate simplicity of 29
Domain model, disambiguating 29
Domain model, domain classes and 24 30
Domain model, feeding updated information and changes back into 51
Domain model, identifying attributes to be added to classes 125
Domain model, not mistaking for a data model 28
Domain model, refining and updating throughout a project 23
Domain model, relationship to use cases 25
Domain model, removing UI elements from 32
Domain model, showing aggregation and generalization relationships 24 27
Domain model, updating after identifying a new domain object 122
Domain model, updating incrementally while drawing robustness diagrams 125
Domain model, using as a project glossary 24 26 29
Domain model, when to update 51
Domain modeling 3
Domain modeling, creating the initial model in two hours 28
Domain modeling, definition of 7
Domain modeling, distinguishing domain models from data models 7
Domain modeling, exercises and solutions for spotting modeling errors 39—42 44—45
Domain modeling, focusing on real-world objects within the problem domain 26
Domain modeling, guidelines 7 26
Domain modeling, identifying and eliminating duplicate terms 32
Domain modeling, practice questions in modeling 45—46
Domain modeling, static and dynamic parts of 25
DomainObject interface 315
doSubmitAction() 283 290
dot notation 423
Drawing a robustness diagram 3 11
Driving test cases from the analysis model 20
DUnit 339
Dynamic workflows 2
Dysfunctional requirements, definition of 375
Edit Customer Review use case 324
|
|
|
| Реклама |
|
|
|
|
|
О проекте