Ad
More Related Content
What's hot (20)
Similar to Software engineering principles in system software design (20)
Ad
More from Tech_MX (20)
Ad
Recently uploaded (20)
Software engineering principles in system software design
- 1. Software Engineering Principles in System Software Design 1 9/3/2012
- 2. Agenda 2 Introduction Definition of Software Engineering Principles of Software Engineering Example –Compiler Software Development Process Example –Assembler Conclusion 9/3/2012
- 3. Introduction 3 The development of software engineering tools and methods began in the late 1960’s. The problems in managing a large development project led to increases in development costs and decreases in productivity. Software Engineering evolved gradually in response to the problems of cost, productivity and reliability created by large and complex software systems. These principles are not only applicable to application software but also for the system software. 9/3/2012
- 4. Software Engineering: Definition 4 A collection of techniques, methodologies, and tools that help with the production of a high quality software system with a given budget before a given deadline 9/3/2012
- 5. Principles of Software Engineering 5 Rigor and formality Separation of concerns Modularity Abstraction Anticipation of change Generality Incrementality 9/3/2012
- 6. Rigor and Formality 6 Rigor means strict precision Rigor helps to produce products with higher reliability, greater quality while controlling costs and meeting expectations. Various degrees of rigor can be achieved Formality is the highest degree of rigor Formality enables tool support Degree of rigor depends on application 9/3/2012
- 7. Separation of concerns 7 To dominate complexity, separate the issues to concentrate on one at a time. Divide & conquer. Supports parallelization of efforts and separation of responsibilities. 9/3/2012
- 8. Modularity 8 A complex system may be divided into simpler pieces called modules A system that is composed of modules is called modular Supports application of separation of concerns when dealing with a module we can ignore details of other modules 9/3/2012
- 9. Cohesion and coupling 9 Each module should be highly cohesive. Module understandable as a meaningful unit Components of a module are closely related to one another Modules should exhibit low coupling. Modules have low interactions with others Understandable separately 9/3/2012
- 10. A visual representation 10 (a) (b) High coupling Low coupling 9/3/2012
- 11. Abstraction 11 Identify the important aspects of a phenomenon and ignore its details. Special case of separation of concerns. The type of abstraction to apply depends on purpose. 9/3/2012
- 12. Anticipation of change 12 Ability to support software evolution requires anticipating potential future changes. It is the basis for software evolvability. 9/3/2012
- 13. Generality 13 While solving a problem, try to discover if it is an instance of a more general problem whose solution can be reused in other cases. Carefully balance generality against performance and cost. Sometimes a general problem is easier to solve than a special case . 9/3/2012
- 14. Incrementality 14 Process proceeds in a stepwise fashion (increments) Examples (process) Deliver subsets of a system early to get early feedback from expected users, then add new features incrementally. Deal first with functionality, then turn to performance. Deliver a first prototype and then incrementally add effort to turn prototype into product. 9/3/2012
- 15. Example -Compiler 15 Rigor and Formality: Compiler Compilers are critical products Errors are multiplied on a mass scale Very high degree of formalization regular expressions, grammars Formalization enables tool support Scanner generators (lex) Parser generators (yacc) 9/3/2012
- 16. Separation of Concerns: Compiler 16 Correctness is primary concern Other concerns Efficiency of compiler and of generated code User friendliness (helpful warnings, etc.) Example for interdependencies: runtime diagnostics and efficient code Example: runtime assertion checking Diagnostics simplify testing, but create overhead Typical solution: option to disable checks 9/3/2012
- 17. Modularity: Compiler 17 Compilers are modularized into phases Each phase has precisely defined input and output High cohesion: common functionality in each phase Low coupling: pipe-and-filter architecture, symbol table Symbol Table Source code object code Semantic Code Lexical Analysis Parsing Analysis Generation 9/3/2012
- 18. Abstraction: Compiler 18 Abstract syntax to neglect syntactic details such as begin…end vs. {…} to bracket statement sequences. Abstract syntax Abstract while loop syntax: while( BoolExpr Stmt ) Concrete Pascal syntax WHILE BoolExpr DO Stmt ; Concrete Java syntax: while ( BoolExpr ) Stmt 9/3/2012
- 19. Abstraction: Compiler 19 Code Generation Intermediate Code Co Assembler Code Optimization Generation Generation 9/3/2012
- 20. Anticipation of Change: Compiler Case Study 20 Typical changes New versions of processors and operating systems . New target machines . Language and library extensions (e.g., standards) . 9/3/2012
- 21. Incrementality :Compiler Case Study 21 Language can be extended incrementally Compiler can be enhanced incrementally Supported language subset Runtime diagnostics Optimizations 9/3/2012
- 22. Software Development Process 22 In the water fall model, the software development effort is pictured as flowing through a sequence of different stages as given below Requirement Analysis System Specification System Design Implementation System Testing Maintenance 9/3/2012
- 23. Software Development Process 23 Requirement Analysis • The focus of this stage is on the needs of the users of the system . • The requirements specify what the system must do, but not how it will be done. • The result of the this stage is a requirement document. 9/3/2012
- 24. Software Development Process contd.. 24 System Specification • The goal of this stage is to formulate a precise description of the desired system. • The requirements analysis step looks at the system from the point of view of the end user. • The system specifications are written from the point of view of system developers and programmers. 9/3/2012
- 25. Software Development Process contd.. 25 System Design • This stage begins to address the solution itself. • The system design document outlines the most significant characteristics of the software to be developed. Implementation • In this stage of the development process ,the individual modules or objects described by the design process are coded and preliminary testing is done. 9/3/2012
- 26. Software Development Process contd.. 26 System testing • This phase is usually the most expensive and time consuming part of the software development process. • Several different levels of testing are involved. Maintenance • This is the last phase of the Software life-cycle model. • Maintenance can be made much easier and less costly by the presence of good documentation. • The document created during the system development should be kept throughout the lifetime of the system. 9/3/2012
- 27. System Specifications -Assembler 27 Types of specifications • Input specifications Label Operation field An instruction operand Source program 9/3/2012
- 28. System Specifications contd.. 28 • Output specifications Current location Object program • Quality specifications Processing time 9/3/2012
- 29. System design- Procedural System Design 29 Data flow diagram Object program Source Assemble program program Assembly listing 9/3/2012
- 30. Modularized Assembler Design 30 Assembler Pass _1 Pass_2 P1_assign_ Access_int P2_assemb P2_write_ P1_read_src P1_assign_loc P2_write_list sym _file le_inst obj Access_symtab P2_search_optab 9/3/2012
- 31. System Testing 31 A large software System, composed of many thousands of lines of Source code. These are almost too complex to be debugged effectively all at once , when error occur there are too many places to look for them. Most of systems are tested in a series of stages. In each stage the amount of code being debugged is kept small. So it can be tested thoroughly and efficiently. 9/3/2012
- 32. Levels of Testing 32 Unit Testing Black box testing White box testing Integration Testing System Testing - Alpha testing - Beta testing Acceptance Testing 9/3/2012
- 33. Sequences for Testing 33 Bottom–Up Testing Top-down Testing 9/3/2012
- 34. Conclusion 34 Thus System Software also has the principles for its design. Software Engineering Principles are not only applicable to compilers and assemblers but also for other System software like operating system , linker and loader . 9/3/2012
- 35. Reference 35 • Leland L . Beck , System software-An introduction to System Programming. • http://www.d.umn.edu/~gshute/softeng/principles.html 9/3/2012
- 36. 36 Thank You 9/3/2012