: Network Disk Download
Editorial recommendationsThe editor's book reflects the author's experience of structuring systems and teaching software engineering courses for over more than 10 years. We find that students often study programming techniques and software engineering techniques in isolation, often choosing small problems as examples. The result is that students are able to effectively address well-defined issues, but often feel helpless when they first truly face complex and real development projects. The real development process requires a number of different technologies and tools that require collaboration between developers. In view of this situation, the current software engineering undergraduate curriculum system usually includes a course of project management, which teaches the knowledge necessary to organize into a development project.[1]Book Introduction Edit
Tools: UML, Java, and design patterns
There is always a course in our minds when writing this book. This project can also be used in other contexts, such as short-term training or short-term research and development projects, in addition to being designed as a course. We use examples from real systems and examine the interactions between modern technologies such as UML, Java-based technologies, design patterns, design principles, configuration management, and quality control. In addition, we discussed issues related to project management, which are related to the technology and its impact on complexity and change. Foreword editor more than 10 years ago, I learned about a software engineering course taught by Bernd Bruegge of Carnegie Mellon University (CMU). In many other universities ' software engineering courses, it is common practice to divide the four-to-five students into a group in one semester and assign a few small questions or projects to each group, each of which has a period of less than one months for each small issue or project. In these small projects, there is a strong master programmer, usually through the strong drive of the main programmer to promote the work of the whole team to complete these small projects. In this context, students often do not need to learn communication skills, there is no need to use modeling tools, there is no need to deal with the actual problem of ambiguity. Students trained in this environment have not learned how to deal with the complexities of developing real projects. In Professor Bruegge's course, the whole class was completing the same project throughout the semester: developing a query-oriented navigation system for Pittsburg. Students have to complete further development on the basis of the interactive system developed by the students in the previous semester. The customer is the manager and domain authority of the city Planning department. In this project, geographic data and car scheduling data are imprecise, incompatible format, at the end of the school year, students completed a system of more than 27 000 lines of code, the system is ultimately accepted by customers. This result is much different from the software engineering projects that many other institutions use in teaching. Students at CMU understand the strategies, organizations, and tools needed to deal with the complexities and clutter of the real world by learning the course. Students learn software engineering courses by practicing in examples, which is the only way to learn any skill. This book reflects the use of software development as a practical philosophy of engineering disciplines. The author adopts a viewpoint--a method of using UML object-oriented, which makes many aspects of software engineering to be understood by students. These include the modeling techniques needed to complete the actual project, and communication skills between people. In addition to this, there is a section on how to manage changes, which is a topic that appears in every practical project, but is often overlooked in other software engineering books. Reading this book will give readers a deep understanding of the rich scope and complexity of software engineering. Catalogue Edit Catalogue Translator's words I preface III Preface v Acknowledgment XI part 1th start 1thChapter 31.1 Introduction: Software Engineering error 31.2 What is software engineering 51.2.1 modeling 61.2.2 Problem Solving 71.2.3 knowledge acquisition 81.2.4 Fundamentals 81.3 Software Engineering Concepts 91.3.1 participants and roles 91.3.2 systems and models 101.3.3 Work Products 111.3.4 activities, tasks and resources 111.3.5 functional requirements and non-functional requirements 121.3.6 notation, methodology and methodology 121.4 software engineering development activities 131.4.1 requirements Acquisition 131.4.2 Analysis 141.4.3 system design 161.4.4 Object Design 161.4.5 implementation 161.4.6 test 171.5 management software development 171.5.1 Communication 171.5.2 Fundamentals Management 181.5.3 software Configuration Management 181.5.4 project management 181.5.5 software life cycle 191.5 .6 Summary 191.6 Arena Instance Analysis 191.7 recommended readings 201.8 Exercise 21 2nd Use UML for modeling 222.1 Introduction 222.2 UML Review 232.2.1 use case diagram 232.2.2 class diagram 242.2.3 interaction diagram 252.2.4 Status Machine 252.2.5 Activity Figure 262.3 Conceptual 272.3.1 systems, models, and viewpoints 272.3.2 data types, abstract data types, and instances in modeling activities 292.3.3 classes, abstract classes, and objects 292.3.4 event classes, events, and messages 312.3.5 object-oriented modeling process 3 12.3.6 reduction expression and prototype construction 332.4 UML in-depth perspective 342.4.1 use case diagram 342.4.2 class diagram 392.4.3 interaction diagram 472.4.4 State machine 492.4.5 activity diagram 512.4.6 diagram expansion of organization 532.4.7 diagram 552.5 Recommended Readings 562.6 Exercise 56 3rd Project organization and Communication 583.1 Introduction: An example of a rocket 583.2 Project overview 593.3 Project management concept 623.3.1 project management 623.3.2 role 653.3.3 tasks and work product 673.3.4 progress Table 683.4 concept of project communication 693.4.1 planned communication 693.4.2 unplanned Communication 743.4.3 Communication mechanism 773.5 organized activities 833.5.1 join a project team 833.5.2 use communication infrastructure 843.5.3 participate in project team situation Ventilation Conference 843.5.4 organization Customer and project summary 863.6 recommended readings 873.7 Exercise 87 Part 2 Complexity processing 4th Chapter Requirements Acquisition 914.1 Introduction: Availability instance 914.2 Total view of demand acquisition 924.3 requirements acquisition Concept 944.3.1 Functional Requirements 944.3.2 Non-functional requirements 944.3.3 End Integrity, consistency, clarity and correctness 954.3.4 reality, validation and traceability 964.3.5 Greenland engineering, re-engineering and interface engineering 974.4 requirements acquisition activity 974.4.1 identity Participant (actor) 984.4.2 identify the scene 994.4.3 identify use case 1014. 4.4 Refinement Case 1034.4.5 identifies the relationship between the actor and the use case 1054.4.6 identifies the initial analysis object 1084.4.7 identification non-functional requirements 1104.5 requirements acquisition Management 1114.5.1 and Customer Consultation Specification: Joint application design 1124.5.2 tracking dimension Protection 1134.5.3 1144.6 Arena Case Study 1154.6.1 initial issue statement 1154.6.2 identity participant and scene 1174.6.3 identify use case 1204.6.4 refinement use case and identity relationship 1224.6.5 identification non-functional requirements 1 Lessons to be accepted by 264.6.6 1264.7 recommended readings 1274.8 Exercise 128 5th Analysis 1305.1 Introduction: Light Phantom 1305.2 Analysis Overview 1315.3 Analysis concept 1325.3.1 object model and dynamic model analysis 1325.3.2 entities, boundaries, and Control object 1325.3.3 generalization and specialization 1345.4 analysis activity: Identifying entity objects from use case to object 1345.4.1 identity boundary object 1375.4.3 Identity Control object 1385.4.4 use sequence diagram to map use case to object 1395.4.5 using C Interaction between RC Card modeling Objects 1425.4.6 Identity Association 1435.4.7 Identity Aggregation 1455.4.8 Identity Properties 1465.4.9 modeling the state-related behavior of a single object the inheritance relationship between 1475.4.10 modeling objects 1485.4.11 analysis Model review 1485 .4.12 Analysis Summary 1495.5 analysis management 1505.5.1 Analysis Documentation 1515.5.2 allocation responsibility 1515.5.3 Analysis Communication 1525.5.4 Analysis model Iteration 1535.5.5 customer End information 1545.6 Arena Case Study 1 565.6.1 Identifying entity Objects 1565.6.2Identity Boundary Object 1595.6.3 Identity Control object 1605.6.4 Modeling interaction 1615.6.5 Evaluation and reinforcement analysis model the lessons to be learned in 1635.6.6 1655.7 recommended reading 1665.8 Exercise 166 the 6th Chapter System design: Decomposition system 1686. 1 Introduction: An example of a floor plan 1686.2 system Design Overview 1706.3 System design Concept 1716.3.1 subsystem and Class 1716.3.2 service and subsystem interface 1726.3.3 coupling and cohesion 1736.3.4 layering and partitioning 1766.3.5 architecture style 1786.4 system Design Activities: from object to subsystem 1846.4.1 starting point: The analysis model of the route planning system 1846.4.2 Logo design target 1866.4.3 identification Subsystem 1886.5 recommended readings 1906.6 Exercise 190 7th System design: Select Design Goal 192 7.1 Introduction: Example of a redundant system 1927.2 system Design Activity Overview 1937.3 concept: UML deployment Diagram 1957.4 System design activity: Select design target 1967.4.1 to map the subsystem to the processor and the artifacts on the 1967.4.2 identity and store the persistence data 1977.4. 3 providing access control 2007.4.4 design Global control Flow 2057.4.5 identity Service 2077.4.6 identity boundary condition 2087.4.7 Review System Design 2107.5 management system Design 2127.5.1 system Design file 2127.5.2 responsibility assignment 2137.5 .3 System Design AC 2147.5.4 system design iterative 2157.6 Arena case study 2167.6.1 identity design target 2167.6.2 identification Subsystem 2177.6.3 maps the subsystem to the processor and artifacts 2187.6.4 identifies and stores the persistence data 2207. 6.5 Providing access control 2207.6.6 design Global control Flow 2217.6.7 identity Service 2227.6.8 identity boundary Condition 2247.6.9 Course Summary 2267.7 recommended reading 2267.8 exercise 227 8th Object Design: Reuse Mode resolution 2288.1 Introduction: Frustration 2288.2 Object Design Overview 2308.3 Reuse Concept: Solution Object, inheritance and design pattern 2328.3.1 Application object and Object reconciliation 2328.3.2 definition inheritance and implementation inheritance 2338.3.3 authorization 2358.3.4 Liskov replacement guideline 2358.3.5 Authorization and inheritance in design mode 2368.4 reuse activity: Selecting design Patterns and artifacts 2388.4.1 using bridge mode to encapsulate data stores 2398.4.2 legacy artifacts encapsulated by adapter mode 2408.4.3 using Strategy pattern wrapper context 2428.4.4 use abstract Factory mode package platform 2448.4.5 using command mode to encapsulate control flow 2458.4.6 heuristic criteria for packaging hierarchy with composite design pattern 2468.4.7 Selection design mode 2488.4.8 logo and adjustment application framework 2488.5 management multiplexing 2528.5.1 document editing multiplexing 2538.5.2 assigning responsibility 2548.6 Arena case study 2548.6.1 using the abstract factory design mode 2558.6.2 using command design mode 2568.6.3 using Observer Model 2578.6.4 Course Review 2578.7 recommended readings 2588.8 Exercise 258 9th Object Design: Description Interface 2609.1 Introduction: Example of a railway 2609.2 Interface Specification Overview 2619.3 Interface Specification Concept 2629.3.1 class implementation class Extender and class user 2639.3.2 type, signature, and visibility 2649.3.3 contract: invariant, preconditions, and post-conditions 2659.3.4 object constraint language 2669.3.5 OCL collection: Collection, bag, and sequence 2699.3.6 OCL quantifier: Universal quantifier forall and existence quantifier exists 2729.4 Interface Specification activity 2729.4.1 identity missing attributes and operations 2739.4.2 description type, signature and visibility 2749.4.3 description preconditions and post conditions 2759.4.4 description invariant 2779.4.5 Inheritance contract 2789.5 Object Design Management 2809.5.1 Object Design documentation 2809.5.2 allocation responsibility 2859.5.3 use contract 2859.6 Arena case analysis in demand Analysis 2869.6.1 logo in series style tournament Actions omitted in style and turn round 2869.6.2 definition Description series style Tournamentstyle and the contract in the round round 2889.6.3 Definition description Knockout style Knockoutstyle and elimination rounds Knockoutround?????? Contract 2909.6.4 Course review 2919.7 recommended readings 2919.8 Exercise 292 The 10th chapter maps the model to code 29410.1 Introduction: An example of a book 29410.2 mapping overview 29510.3 mapping Concept 29610.3.1 model conversion 29610.3.2 Reconstruction 29710.3.3 forward Engineering 29910.3.4 Reverse engineering 30010.3.5 Conversion principle 3001 0.4 Mapping activity 30110.4.1 Optimizing an object Design Model 30110.4.2 Mapping an association to a collection 30410.4.3 mapping a contract to an exception 30810.4.4 mapping the object model to persistent storage mode 31210.5 Management Implementation 31710.5.1 Archive process conversion 3 1710.5.2 assignment of Duties 31810.6 Arena case study 31810.6.1 the statistical class statistics 31910.6.2 in the Arena system arena to map the association to the collection 32010.6.3 map the contract to the exception 32210.6.4 the object model Mapping to database Schema 32310.6.5 course review 32410.7 recommended readings 32410.8 Exercise 325 11th Test 32711.1 Introduction: Test Space Shuttle 32711.2 Test Overview 32911.3 Test Concepts 33211.3.1 Fault, Error state, and loss Effect 33311.3.2 test case 33511.3.3 Test pile and test drive 33711.3.4 correction 33711.4 Test Activity 33811.4.1 Component Check 33811.4.2 availability Test 33911.4.3 Unit Test 34011.4.4 Integration test 34811.4.5 System Test 35211.5 Management test 35611.5.1 develop a test plan 35611.5.2 write a test document 35711.5.3 assign responsibilities 35911.5.4 regression test 36011.5.5 make test automation 36111.5.6 based on Model test 36211.6 recommended readings 36411.7 Exercise 365 Part 3 Change Management 12th Chapter Basic Principles Management 36912.1 Introduction: Cut ham into thin slices 36912.2 Fundamentals overview 37012.3 Basic Concepts 37212.3.1 Centralized traffic control 37312.3.2 definition problem: Problem 37412.3.3 exploration problem space: proposed 37512.3.4 evaluation solution space: criteria and discussion 37612.3.5 The solution space crash: Solutions 37712.3.6 Execution Solution: Activity Item 37812.3.7 problem-based modulo Model and System example 37912.4 Fundamentals of activity: from the problemTo the decision 38212.4.1 CTC system design 38212.4.2 get the fundamentals in the meeting 38312.4.3 the basic principle of asynchronous acquisition 38912.4.4 the basic principle of acquiring when a change is discussed 39112.4.5 the fundamentals of 39312.5 Management Fundamentals 3 9512.5.1 the rationale for documenting 39512.5.2 assignment tasks 39612.5.3 heuristic rules for communication of basic principles 39712.5.4 Problem model and negotiation 39712.5.5 conflict resolution strategy 39912.6 recommended readings 40012.7 Exercise 400 1th Chapter 3 Configuration Management 40213.1 Introduction: An example of an aircraft 40213.2 Configuration Management Overview 40413.3 Configuration Management Concepts 40513.3.1 configuration items and cm aggregation 40613.3.2 version and Configuration 40613.3.3 change request 40713.3.4 upgrade and Publish 40713.3.5 warehouse and workspace 40713.3.6 version identification scheme 40813.3.7 change and change set 40913.3.8 configuration management tools 41013.4 Configuration Management activity 41113.4.1 configuration items and cm aggregation identity 41313.4.2 upgrade Management 41413.4.3 Release Management 41513.4.4 Branch Management 41713.4.5 different version management 41913.4.6 change Management 42113.5 management of configuration Management 42213.5.1 Configuration Management documentation 42213.5.2 assigning configuration management Responsibility 42 313.5.3 Planning Configuration Management Activities 42413.5.4 Continuous integration: test activities and improved management 42413.6 recommended readings 42613.7 Exercise 426 14th Project Management 42814.1 Introduction: STS-51L Launch decision 42814.2 Project Management Overview 43014 .3 Project Management Concepts 43414.3.1 tasks and activities 43414.3.2 work products, work packages, and roles 43514.3.3 work breakdown structure 43614.3.4 task Model 43614.3.5 skill matrix 43714.3.6 Organization 43814.3.7 Visual organization Structure 44014.3.8 organization structure Atlas 44014.3.9 Software project management plan 44114.4 Project management activities 44314.4.1 planning Project 44414.4.2 Organization Project 44814.4.3 control Project 45114.4.4 finalization Project 45514.5 Agile Project Management Activities 45614.5.1 ProjectPlan: Create product and Sprint backup 45714.5.2 Organization Project 45714.5.3 Control project: Sprint and Fire extinguishing table per day (burn down charts) 45814.5.4 termination project: Comments on sprints 45914.6 recommended readings 46014.7 Exercise 460 15th. Software Lifecycle 46215.1 Introduction: Polynesian Voyage 46215.2 IEEE 1074: Standard 46515.2.1 processes and activities for developing software lifecycle processes 46515.2.2 software life cycle Modeling 46715.2.3 project Management 46715.2.4 Early development 46815.2.5 Development process 46815.2.6 later development 46915.2.7 overall process (cross-development process) 47015.3 reviews maturity of software life cycle Model 47115.4 life cycle model 47215.4.1 model with sequential activity-centric 473 15.4.2 an iterative activity-centric model 47515.4.3 entity-centric model 47915.5 recommended readings 48115.6 Exercise 481 16th Methodology: Comprehensive consideration of various factors 48316.1 introduction: First Climbing heros (K2 PK) 48316.2 Project Environment 48616.3 Methodological issues 48816.3.1 How many plans need to be made 48816.3.2 need to consider the extent to which multiplexing 48916.3.3 need to build how many models 48916.3.4 process contains how many steps 49016.3.5 need to control and monitor 4911 6.3.6 when to redefine a project objective 49216.4 law Field 49216.4.1 Royce Methodology 49316.4.2 Extreme Programming (XP) 49616.4.3 Rugby methodology 50016.5 Case study 50516.5.1 XP project: ATRAC T 50616.5.2 Local main customer: FRIEND 50816.5.3 Distributed project: JAMES 51316.5.4 Case Study summary 51816.6 recommended readings 52116.7 Exercise 521 Part 4 Appendix Appendix A design Pattern 525a.1 Abstrac T Factory: Package platform 525a.2 Adapter: Packaging Legacy code 526a.3 Bridge: Allow selective implementation 527a.4 Command: Encapsulates the control flow 527a.5 Composite: A hierarchy that represents recursion 528a.6 Facad E: Package Subsystem 529a.7 Observer: WillEntity detached from view 529a.8 Proxy: Encapsulates an object with a large overhead 530a.9 strategy: The heuristic criteria for packaging algorithm 531a.10 selecting design Patterns 532 Appendix B Glossary 533 Appendix C Reference 557
: Network Disk Download
Object-oriented Software engineering: Working with UML, schemas, and Java (3rd edition) pdf
