Luận án tiến sĩ: Enhanced UML Model Checking - George Mason University
Luận án tiến sĩ nghiên cứu Enhanced UML Model Checking cho phần mềm kinh doanh. Đề xuất phương pháp mô hình hóa cải tiến, nâng cao chất lượng thiết kế và xác minh.
George Mason University
Information Technology
Luan An
Luận án
Năm xuất bản
Số trang
258
Thời gian đọc
39 phút
Lượt xem
0
Lượt tải
0
Phí lưu trữ
50 Point
Mục lục chi tiết
Tóm tắt nội dung
I. UML Model Checking cho Ứng dụng Phần mềm Kinh doanh
UML Model Checking đại diện cho phương pháp tiên tiến trong việc xác minh tính đúng đắn của thiết kế phần mềm. Công nghệ này kết hợp sức mạnh của Unified Modeling Language với các kỹ thuật formal verification. Mục tiêu chính là phát hiện lỗi thiết kế sớm trong chu trình phát triển phần mềm. Đối với ứng dụng kinh doanh, việc này đặc biệt quan trọng vì tính phức tạp của business process modeling. UML verification giúp đảm bảo rằng các mô hình thiết kế phản ánh chính xác yêu cầu nghiệp vụ. Phương pháp này sử dụng temporal logic và OCL constraints để kiểm tra tính nhất quán. Model validation trở thành bước không thể thiếu trước khi triển khai code. Các sơ đồ như state machine diagram, activity diagram và sequence diagram được kiểm tra tự động. Kết quả là giảm thiểu chi phí sửa lỗi và tăng chất lượng phần mềm.
1.1. Tầm quan trọng của UML trong phát triển phần mềm
Phát triển phần mềm gặp khó khăn khi thiếu UML modeling. Các dự án không có blueprint rõ ràng thường dẫn đến sự hiểu lầm giữa các thành viên nhóm. UML cung cấp ngôn ngữ trực quan chung cho developers, business analysts và stakeholders. Sơ đồ UML trở thành công cụ giao tiếp hiệu quả thay thế cho tài liệu dài dòng. Việc thiếu mô hình chuẩn hóa tạo ra rủi ro cao trong quá trình implementation.
1.2. UML diagrams như bản thiết kế thảo luận
UML diagrams đóng vai trò như blueprint để thảo luận giữa các bên liên quan. Mỗi loại diagram phục vụ mục đích cụ thể trong việc mô tả hệ thống. Class diagrams thể hiện cấu trúc tĩnh của các đối tượng và mối quan hệ. Sequence diagrams minh họa tương tác theo thời gian giữa các components. Activity diagrams mô tả luồng công việc và business processes. Việc sử dụng các diagrams này giúp team alignment và giảm thiểu miscommunication.
1.3. Mức độ trừu tượng phù hợp cho business domain
UML checking cho business domain yêu cầu mức độ abstraction phù hợp. Quá chi tiết sẽ làm mất tính linh hoạt và khó bảo trì. Quá trừu tượng lại không đủ thông tin để implementation chính xác. Business software applications cần cân bằng giữa business logic và technical details. Model validation phải kiểm tra cả business rules lẫn technical constraints. OCL constraints giúp định nghĩa các điều kiện nghiệp vụ một cách chính xác.
II. Formal Methods trong UML Verification Process
Formal methods mang lại độ chính xác toán học cho UML verification. Các phương pháp này sử dụng logic hình thức để chứng minh tính đúng đắn của mô hình. Temporal logic cho phép biểu diễn các thuộc tính về thời gian và trạng thái. Model checking tự động kiểm tra xem mô hình có thỏa mãn specifications hay không. Đối với business software, formal verification phát hiện deadlocks, race conditions và inconsistencies. State machine diagrams được phân tích để đảm bảo tất cả trạng thái đều reachable. Activity diagrams được kiểm tra về tính completeness và correctness của business workflows. OCL constraints được validate để đảm bảo business rules được thực thi đúng. Phương pháp này giúp phát hiện lỗi mà testing thông thường có thể bỏ sót. Kết quả là hệ thống đáng tin cậy hơn và ít lỗi runtime.
2.1. Temporal logic trong model checking
Temporal logic cung cấp framework để mô tả các thuộc tính phụ thuộc thời gian. Linear Temporal Logic (LTL) và Computation Tree Logic (CTL) là hai dạng phổ biến. LTL mô tả các thuộc tính trên đường đi tuyến tính qua các trạng thái. CTL cho phép mô tả các thuộc tính trên cây tính toán với nhiều nhánh. Trong business applications, temporal logic kiểm tra các properties như safety và liveness. Safety properties đảm bảo không có điều xấu xảy ra. Liveness properties đảm bảo điều tốt cuối cùng sẽ xảy ra.
2.2. OCL constraints cho business rules
Object Constraint Language (OCL) bổ sung cho UML diagrams bằng các ràng buộc chính xác. OCL định nghĩa invariants, preconditions và postconditions cho operations. Business rules phức tạp được biểu diễn một cách không nhập nhằng. OCL expressions được evaluate tự động trong quá trình model validation. Điều này đảm bảo business logic được implement đúng từ giai đoạn thiết kế. OCL giúp bridge gap giữa business requirements và technical implementation.
2.3. State machine verification techniques
State machine diagrams mô tả behavior của objects qua các states và transitions. Verification techniques kiểm tra reachability của tất cả states trong diagram. Deadlock detection xác định các states không có outgoing transitions hợp lệ. Liveness analysis đảm bảo hệ thống có thể đạt được desired states. Completeness checking xác nhận tất cả events được xử lý trong mọi state. Formal methods tự động hóa việc kiểm tra các properties này trên large state spaces.
III. Business Process Modeling với BPMN và UML
Business Process Modeling Notation (BPMN) và UML activity diagrams cùng phục vụ business process modeling. BPMN được thiết kế đặc biệt cho business analysts với notation dễ hiểu. UML activity diagrams cung cấp cách tiếp cận technical hơn cho software developers. Cả hai đều mô tả workflows, decision points và parallel processes. Model validation đảm bảo business processes không có logical errors. Sequence diagrams bổ sung bằng cách hiển thị interactions giữa các participants. Việc kết hợp BPMN và UML tạo ra comprehensive view của business operations. Model checking phát hiện bottlenecks, redundant steps và missing paths trong processes. OCL constraints enforce business rules tại các decision points. Formal verification đảm bảo processes tuân thủ compliance requirements. Integration giữa process models và system design tăng traceability.
3.1. BPMN vs UML activity diagrams
BPMN focuses on business-level process visualization với symbols quen thuộc. UML activity diagrams integrate tốt hơn với các UML diagrams khác trong system design. BPMN hỗ trợ nhiều loại events, gateways và artifacts cho business modeling. UML activity diagrams mạnh trong việc mô tả concurrent behaviors và exception handling. Lựa chọn giữa hai notation phụ thuộc vào audience và mục đích sử dụng. Nhiều tools hiện nay hỗ trợ cả hai để maximize flexibility.
3.2. Sequence diagrams cho business interactions
Sequence diagrams visualize interactions giữa actors và system components theo timeline. Mỗi message exchange được hiển thị theo thứ tự chronological. Business scenarios được mô tả qua các interaction sequences cụ thể. Lifelines represent các participants trong interaction. Activation boxes show khi nào object đang active trong processing. Combined fragments mô tả loops, alternatives và parallel executions. Model validation kiểm tra message sequences có consistent với state machines không.
3.3. Workflow validation techniques
Workflow validation đảm bảo business processes executable và error-free. Completeness checking xác nhận tất cả paths từ start đến end states. Soundness verification kiểm tra không có deadlocks hoặc livelocks. Resource allocation analysis đảm bảo resources available khi cần. Compliance checking validates processes tuân thủ regulations và policies. Automated model checking tools phát hiện violations sớm trong design phase.
IV. Model Validation Strategies cho Software Quality
Model validation là process đảm bảo UML models chính xác và complete. Strategies bao gồm syntax checking, semantic validation và consistency verification. Syntax checking đảm bảo diagrams tuân thủ UML notation rules. Semantic validation kiểm tra models có ý nghĩa và không contradictory. Consistency verification đảm bảo các diagrams khác nhau không conflict. Formal methods tự động hóa nhiều aspects của validation process. Model-based testing generates test cases trực tiếp từ UML models. Traceability matrices link requirements với design elements trong models. Peer reviews và walkthroughs bổ sung cho automated validation. Tool support như model checkers và validators tăng efficiency. Early validation giảm cost of fixing defects sau trong development cycle. Comprehensive validation strategy cải thiện overall software quality significantly.
4.1. Syntax và semantic validation
Syntax validation kiểm tra UML diagrams tuân theo grammar và notation rules. Automated tools phát hiện malformed diagrams và incorrect symbol usage. Semantic validation goes deeper để ensure models có ý nghĩa business logic. Điều này includes checking for unreachable states, unused elements và logical contradictions. Type checking validates data types consistent across diagrams. Cardinality constraints được verified để ensure valid relationships. Semantic errors thường subtle hơn và require domain knowledge để detect.
4.2. Consistency checking across diagrams
Multiple UML diagrams phải consistent với nhau để form coherent system model. Class diagrams phải align với sequence diagrams về available operations. State machines phải consistent với activity diagrams về possible behaviors. OCL constraints phải compatible với structural elements trong class diagrams. Cross-diagram validation tools automatically detect inconsistencies. Traceability links help maintain consistency khi models evolve. Regular consistency checks prevent drift giữa different views của system.
4.3. Model based testing approaches
Model-based testing derives test cases automatically từ UML models. State machine diagrams generate tests covering all states và transitions. Sequence diagrams produce integration tests cho component interactions. Activity diagrams create workflow tests cho business processes. Coverage criteria ensure comprehensive testing của model elements. Automated test generation saves time và increases test coverage. Model-based tests remain valid khi implementation changes nhưng model không change.
V. Refactoring UML Models cho Design Optimization
Refactoring UML models involves restructuring để improve quality mà không thay đổi functionality. Model refactoring patterns giống code refactoring nhưng applied tại design level. Goals include improving clarity, reducing complexity và enhancing maintainability. Common refactorings include extracting superclasses, merging duplicate elements và simplifying relationships. State machine refactoring consolidates redundant states và transitions. Activity diagram refactoring eliminates unnecessary steps trong workflows. Sequence diagram refactoring optimizes message exchanges giữa components. OCL constraints được refined để express business rules more precisely. Refactoring maintains semantic equivalence while improving model structure. Automated refactoring tools preserve model correctness during transformations. Strategic refactoring enables better software reuse và extensibility. Well-structured models facilitate easier understanding và modification over time.
5.1. Structural refactoring patterns
Structural refactoring improves class diagram organization và relationships. Extract superclass pattern identifies common attributes và methods để create inheritance. Merge classes pattern combines duplicate hoặc highly similar classes. Split class pattern breaks down complex classes into smaller, focused ones. Introduce interface pattern defines contracts cho related classes. Move attribute/method patterns relocate elements đến more appropriate classes. These patterns reduce duplication và improve cohesion trong design.
5.2. Behavioral refactoring techniques
Behavioral refactoring optimizes state machines, activity và sequence diagrams. Merge states pattern combines states với identical behaviors. Extract substate pattern decomposes complex states into hierarchical structures. Simplify transition pattern reduces unnecessary transition paths. Reorder activities pattern optimizes workflow execution sequence. Consolidate messages pattern reduces chattiness trong sequence diagrams. Behavioral refactoring maintains observable behavior while improving internal structure.
5.3. Refactoring impact on model validation
Refactoring requires re-validation để ensure correctness maintained. Automated validation tools quickly verify refactored models. Regression testing confirms no unintended behavior changes introduced. Traceability links must be updated sau refactoring operations. Version control tracks model evolution và enables rollback nếu needed. Incremental validation during refactoring catches errors early. Well-defined refactoring operations with proven correctness reduce validation overhead.
VI. Strategic Naming và Software Reuse trong UML
Strategic naming conventions trong UML models dramatically improve comprehension và reuse. Consistent naming enables developers quickly understand model elements. Domain-specific terminology trong names bridges gap giữa business và technical teams. Clear naming reduces need cho extensive documentation và explanations. Naming standards facilitate searching và locating relevant model components. Well-named elements promote software reuse by making purpose obvious. UML model checkers leverage naming patterns để detect potential issues. Systematic naming supports automated code generation từ models. Namespace management prevents naming conflicts trong large systems. Naming guidelines should cover classes, attributes, operations, states và transitions. Good names self-document the model và reduce maintenance effort. Strategic naming combined với model validation creates high-quality, reusable designs. Reusable UML components accelerate development của new applications. Pattern libraries với well-named elements enable rapid composition của solutions.
6.1. Naming conventions cho UML elements
Naming conventions establish consistent patterns cho all UML elements. Classes use noun phrases describing entities trong domain. Operations use verb phrases indicating actions performed. Attributes use noun phrases describing properties. States use adjectives hoặc past participles describing conditions. Transitions use verb phrases describing triggering events. Packages use noun phrases grouping related elements. Consistent capitalization và word separation improve readability. Abbreviations should be avoided unless universally understood.
6.2. Domain terminology integration
UML models should use terminology familiar đến domain experts. Business terms trong model names facilitate communication với stakeholders. Ubiquitous language from domain-driven design should reflect trong models. Glossaries define domain terms used consistently across diagrams. Domain-specific naming makes models self-explanatory đến business users. Technical jargon should be minimized trong business-facing models. Alignment giữa model names và business vocabulary improves validation accuracy.
6.3. Reusable component identification
Strategic naming helps identify candidates cho reusable components. Generic, well-named elements indicate potential reuse across projects. Pattern-based naming highlights design patterns implemented trong models. Abstract classes và interfaces với clear names promote extensibility. Well-defined boundaries và responsibilities enable component extraction. Reuse libraries organized by domain và function accelerate development. Model validation ensures reusable components maintain quality standards across uses.
Tải xuống file đầy đủ để xem toàn bộ nội dung
Tải đầy đủ (258 trang)Trích đoạn nội dung luận án
Tải xuống để đọc toàn bộEnhanced Unified Modeling Language Model-Checking For Business Software Applications A dissertation submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy at George Mason University By - John C. Zubeck Bachelor Of Arts University Of Virginia, 1979 Master Of Science Howard University, 1984 Director: David C. Rine, Professor The Volgenau School of Information Technology and Engineering Fall Semester 2006 George Mason University Fairfax, Virginia UMI Number: 3239476 Copyright 2007 by Zubeck, John C. All rights reserved.
INFORMATION TO USERS The quality of this reproduction is dependent upon the quality of the copy submitted. Broken or indistinct print, colored or poor quality illustrations and photographs, print bleed-through, substandard margins, and improper alignment can adversely affect reproduction. In the unlikely event that the author did not send a complete manuscript and there are missing pages, these will be noted. Also, if unauthorized copyright material had to be removed, a note will indicate the deletion.
® UMI UMI Microform 3239476 Copyright 2007 by ProQuest Information and Learning Company. All rights reserved. This microform edition is protected against unauthorized copying under Title 17, United States Code. ProQuest Information and Learning Company 300 North Zeeb Road P.
Box 1346 Ann Arbor, MI 48106-1346 ENHANCED UNIFIED MODELING LANGUAGE MODEL-CHECKING FOR BUSINESS SOFTWARE APPLICATIONS by John C. Zubeck A Dissertation Submitted to the Graduate Faculty of George Mason University in Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy Information Technology Committee: ® Ú “Ys David C. Rine, Dissertation Director “Crete TV ¬ VÀ~ NT: Donald Gantz Lhe ⁄ S — David Schum O Daniel Menascé LEE Daniel Menascé, Associate Dean for an Research and Graduate Studies A A Lloyd J. Griffiths, Dean, The —/ // Volgenau School of Information Technology and Engineering Date: Oc 4 ớ L, er 2 5, 2006 Summer Semester 2006 í George Mason University Fairfax, Virginia ii Dedication To Simone, my darling wife, and to my mother, Carolyn, neither of whom have escaped from the longing to find truth and to do some good in the world.
All life is darkness except where there is urge. All urge is blind except when there is knowledge. All knowledge is in vain except when there is work. All work is empty except when there is love.
--- Kahlil Gibran iii Acknowledgements I would like to express my gratitude to David Rine, my dissertation advisor, for showing me to have faith and to work with patience. I have to thank my first, late wife, Maggie, and my dear daughter, Katie, for the love and encouragement that sustained me earlier in this program. Also my cousin, Veronica Whitehill, has expressed her unflagging support over many years. It is ajoy to express my appreciation for my friend, Steve Ungaro, for inspiring me with how he developed software, fought off cancer, and lived and loved with sheer enthusiasm.
Steve "met with triumph and disaster and treated those two impostors just the same". I certainly would not have finished this program without the advice of my colleague and. friend, Doug Whall, who is raising the quality of technology consulting at Booze Allen and Hamilton. It is a pleasure to acknowledge my friend, Jim Guill, now the chess master, who taught me to first look for the essential subset of knowledge needed for any task.
Also, among my talented friends, I cannot forget my friend and colleague, David Webber, whose thirst for ingenious software triggered my interest in the Prolog software language. I would also like to thank some departed friends but ones who are always with me reminding me always of the value of good writing. Aldeth Spence Christy, thank you for having the integrity to write a journal that spanned a hundred books. Peter Taylor, thank you for teaching me to look for and express powerful truths rather than cleverness in writing.
Also, I would like to thank David and Susana Slayton, the owners and founders of Dynamic Animation Systems, and the many folks at their company who encouraged me and made possible the last year of my program. I greatly appreciate technical dialogs with my friends and colleagues at SAIC, Boeing, Lockheed-Martin, Verizon, Telelogics, Rational Corp., LNK, MCI, the US Army, the engineers at the Naval Surface Warfare Center at Dahlgren, and, of course, fellow students and faculty at George Mason University. iv Table Of Contents Page CHAPTER 1 INTRODUCTION .2 Software Development Flounders Without UML Modeling & Design Diagramming. 3 13 UML Diagrams Become a Blueprint for Discussion 5 1.4 UML Modeling-For-Design in the Business Domain 6 1.5 UML Checking For The Business Domain At The Right Level Of Abstraction 8 1.6 Refactoring: Rearranging the Composition of UML for the Model-To-Design 9 1.7 Strategic Naming Of The Elements That Go Inside UML Diagrams 13 1.8 UML-Model-Checker And Its Methodology Promote Software Reuse 17 1.9 Contributions Of This Research 18 CHAPTER 2 PROBLEM STATEMENT AND HYPOTHESIS.21 First Sub-HypothesiS.
LH HH ng Ho TH Ho TH HC HH HH TH Tư nt 23 2.22 Second Sub-Hypothesis. Án nành HH HH TH TH HC HT TH tr 23 CHAPTER 3 BACKGROUND.1 What Is UML Diagramming And How Is UML Used .2 Impact of UML Modeling On the Software Development Lifecycle 28 3.3 Critical Elements of A Software Accounting System (Domain Example Is Accounting).4 Obstacles to Assisted UML Modeling of Business Software Systems 3.1 Knowledge Representation (KR) Of Business Software Application Model.2 Modeling-To-Design Across Distinctly Different Industries.3 Incompatibilities Among Software Design Paf(erTS.- Án ng HH HH, 3.4 Mapping UML To Data Base Structures & Application Processes.5 Platform-bound Design Elements (Mainframe, Unix, WintelPC, WWW Details) .6 UML-Model Distortion Due To Required Compatibility with Legacy Software System.7 UML-Model Distortion Required To Integrate Commercial-Off-The-Shelf Components .8 UML-Model Necessities Allowing For Future Software Design Flexibility. súng HH HH HH HT TT TH TH 90 3.2 Client Server and/or COIRBA. và HH HH HH Hà HH HT HH Hiệp 3.3 Web Services and XML Registries.- Tà HH H HH4 HH HH tiêu 3.5 Progress in Assisted Software Design of Business Software Systems 3.1 Leveraging Reuse in Modeling-To-Desigit.1 New Software Classes from Parent Classes: Reuse By Object-Oriented Inheritance.2 Product-Line Reuse.- Án HH HH Tu gọn Hàn HH 3.
HH HH HH ng ng gi Ho TH 3.4 Software Design Pattern Capture and Reuse.- HH H2 Ha ro 3.2 Object-Oriented (OO) Impact on Modeling-To-Design.3 Jiri Soukup's Software Design Pattern Classes Organize Software Development.4 Common Object Request Broker Architecture (CORBA).5 Componentware and SAP Industry-Specifie Solution Maps.6 Telon: The Tree-Pruning Approach to Organizing Business Software Development.7 Microsoft Wizard/Agents: A Menu Approach to Business Software Development.8 Magic MSE: Rapid Application Design (RAD) Approach to Software Development .9 University Advances in Expert Systems and Assisted Software Development.1 MIT Model For Intelligent Tutoring Šysfems.2 Zellermayer: Unsolicited Advice from Software ABEeTIS.3 Goldstein & Millers Programming Design Helper.4 PROUST: Using Software Design Goals to Lock Out Errors .5 An Intelligent Agent to Help With Programming (Ted Selker at IBMI). CHAPTER 4 CONSTRUCTING AN IMPROVED UML-MODEL-CHECKER.1 Addressing The Inadequacies Of Rational Rose Checker 82 4.2 Operating Example of the EUMC And SPUDS With IBM/Rational Rose 85 4.3 Large Number Of UML Element Names: Scoping the System Of Object Identifiers.4 Setting The Granularity For Object Identifiers In A Universe Of Discourse 93 4.5 Scope and Limitations Of EUMC 94 4.6 Handling Fidelity Checking Between UML Elements and Outside World 96 4.7 Applying Rules To Groups Of Object Identifiers 97 4.8 XML / XMI Translation Of Object Identifiers From UML Diagrams 99 VI 4.9 Implementation And Construction Of The EUMC Rules 4.1 Introduction To Rule CollectÏ0TWS. HH HỘ Hà HH HH HH HH kiện 4.2 Organizing The Rules In A Way That Fits The Data.3 Implementing Causal Versus Shallow Rules With Procedural Programming.4 Correctness of UML-Checking-Rules.-- Ánh HH Hà HH HH HH ghi, 4.5 Format Of UML Checking-Rules. H20 01101 01 ng ph th 4.6 Defeasibility Of UML-Checking-Rules.- Án ng HH hà, 4.7 Non-Monotonic Characteristics Of Sets Of UML-Checking Rules.8 Avoiding Negative Statement Of UML-Checking Rules 0000.9 When To Build UML-Checking-Rules During The Project Lifecycle .1 Required Element UML-Checking-Rules.
- -- Ăn HH HH HH gi, 4.2 Element-Support UML-Checkỉng-Rules. óc HH Hàng HH HH Hệ, 4. Element-Conflict UML-Checking-Rules. - - Là HH HH nen 4.4 Complimentary-Element UML-Checking-Rules.5 CATEGORY-Element UML-Checking-Rules.10 Building the EUMC With Visual Basic 4.11 The SPUDS Methodology Supporting The EUMC CHAPTER 5 VALIDATION.1 How Can A Thesis Concerning A Software Technology Be Validated? 5.2 Verifying That the EUMC and SPUDS Run on an Average Computer (Standard in 2006).3 Equivalence Partition Testing Compares The EUMC With The RRUC 5.4 Examining The EUMC With A Case Study Performed By A UML Expert CHAPTER6 RESULTS uiccsccssssessssssssesecsessessesscsoess ¬ ¬ ¬ 6.2 Verifying That the EUMC and SPUDS Run on an Average Computer (Standard of 2006).3 Equivalence Partition Testing Results 6.4 Case Study Results 6.1 Summary Of Case Study Questionnaire Responses.2 Complete SME Responses To Case Study Quesfionnaire.
Hee, CHAPTER 7 INTERPRETATION OF RESULTS.1 Assessment of the Main Hypothesis 156 7.2 Assessment Of The Hardware And Support Software Benchmarking 157 7.3 Assessment of the Experimental Testing Of Categories Of UML-Check Rules .4 Assessment Of The Case Study And Resulting Questionnaire vii CHAPTER 8 CONCLUSIONS AND FUTURE WORK.1 Summary Of This Research 160 8.2 Future Work With Model Driven Architecture 162 8.3 Future Work Implementing EUMC Rules In Prolog 163 GLOSSARY. ni ng gọn 165 BIBLIOGRAPPHY. HH nọ nh 170 APPENDIX A. - cọ ni E0 50 176 SAP’s Standard Software Developer’s Guide For Enterprise Structure : 176 APPENDIX.
-Q ch ĐEEEEE 177 Specific-Pre-loaded -UML-Domain-System (SPUDS) 177 APPENDIX C.L LG 000000094 193 Mechanics Of Prototype Of Automatic UML-Model-Checker 193 APPENDIX D.:cssssetceeessessssseeeeeeesssssneneeesessensssseneneeseessenssanenesasuseesesecanansaeeness 195 Vendor Development Tools Fully Or Partially Based On UML Technology 195 APPENDIX eee 203 Rational Rose UML Diagramming Tool Summary 203 APPENDIX F .ccccssssssecceceeeesessseeeeeeeeeeeeeeeeeeeueseesssesusasaesususssseesarsssnensssecsensanenee 205 Significant Changes From UML Version 1 To UML Version 2 205 APPENDIX Ố. ng HH HH TT gọt 209 Wernier Orr Diagram Reference Sample 209 APPENDIX H.- HH HH HH ng Tà me 210 Data Flow Diagram (DFD) Reference Sample. TH ng gọn 211 Unified Modeling Language (UML) Reference Sample 211 APPENDIX K.---- HH nọ TC T010 0 214 SAP Componentware Solution Maps 214 APPENDIX See 219 Microsoft Wizards For Creating Standard Software Business Objects 219 APPENDIX M. nọ lọ lọ BS 0885550080 227 Prolog Source Code For Model Of A Business Enterprise 227 APPENDIX ÑN.QG Gọi EEEEEETEE 235 Summary Of Error Checking Observed In Rational Rose Ver 8.ÔỎ 236 Professional Correspondence With Software Scientists And Engineers 236 CURRICULUM VITAE.
nà nh 245 John C. Zubeck 245 1X List Of Figures Page Figure 1.1 -- A Simple UML Use Case Diagram.2 — All Enterprise Groups Participate In UML Use Case Modeling 5 Figure 1.3 — Essential Subset Of UML Design Is A Combination Use Cases, Packages And Classes.4 -- Standard Building Blocks Used By Business Software Developers [Zubeck97].5 — The Prototype UML-Model-Checker Catches Insufficiencies.6: UML Model Needs Automatic UML-Model-Check To See If Elements In Harmony.7-- Complex Names And Relationships Of An Enterprise And Its Accounting.8 --- How Classification Has Been Applied To Solve Problems.9 -- Categorizing Organizations According To Their Ability To Reuse Software.10 -- Frakes Identifies Reasons Why Software Might Not Be Reused 18 Figure 3.1-- Comparing UML And Some Other Types Of Representation Of Software Projects.2 -- Software Development Life Cycle (SDLC) from Cybermedica Foundation.3 -- IBM/Rational's Sand Chart Describing Effort Level For Each Lifecycle Phase.4 -- Dept Of Defense Engineering Usually Involves Parallel-Subprojects Lifecycle.5 --- A Simple Overview Of Standard Software Accounting Subsystems.6 - Some Of Many Business Forces Causing Shifts In Accounting Practice.7 - Named Enterprise, Accounting, And Software Building Blocks Must Be Merged.8 --- Prolog Language Description Of Expected Patterns In A Business Software System.9 -- Diverse Types Of Companies Whose Different Domains Greatly 40 Figure 3.10 - SAP Solution Map Of Components Needed For Mining Or Healthcare Enterprises.11 -- Classic Software Design Patterns And Their Suggested Relationships.12 -- Collected Information & Collaborations & Conflicts Among Software Design.13 -- Database Representation Of Part Of A Simple Accounting System.
Nội dung được bảo vệ bản quyền — Tải xuống đầy đủ
Từ khóa và chủ đề nghiên cứu
Câu hỏi thường gặp
Luận án "UML Model Checking cho ứng dụng phần mềm kinh doanh" nghiên cứu về vấn đề gì?
Luận án tiến sĩ nghiên cứu Enhanced UML Model Checking cho phần mềm kinh doanh. Đề xuất phương pháp mô hình hóa cải tiến, nâng cao chất lượng thiết kế và xác minh.
Luận án "UML Model Checking cho ứng dụng phần mềm kinh doanh" được bảo vệ tại trường nào?
Luận án này được bảo vệ tại George Mason University. Năm bảo vệ: 2006.
Luận án "UML Model Checking cho ứng dụng phần mềm kinh doanh" thuộc chuyên ngành gì?
Luận án "UML Model Checking cho ứng dụng phần mềm kinh doanh" thuộc chuyên ngành Information Technology. Danh mục: Khoa Học Máy Tính.
Luận án "UML Model Checking cho ứng dụng phần mềm kinh doanh" có bao nhiêu trang?
Luận án "UML Model Checking cho ứng dụng phần mềm kinh doanh" có 258 trang. Bạn có thể xem trước một phần tài liệu ngay trên trang web trước khi tải về.
Cách tải luận án "UML Model Checking cho ứng dụng phần mềm kinh doanh" về máy như thế nào?
Để tải luận án về máy, bạn nhấn nút "Tải xuống ngay" trên trang này, sau đó hoàn tất thanh toán phí lưu trữ. File sẽ được tải xuống ngay sau khi thanh toán thành công. Hỗ trợ qua Zalo: 0559 297 239.