1 / 19

Software Issues

Software Issues. Derived from Dr. Fawcett’s Slides Phil Pratt-Szeliga Fall 2009. Software Issues: Overview. Definitions Software Design Objectives Overview Software Quality Deal with Complexity Management of Change Software Reuse Design in the Application Domain Conclusions.

lucasm
Download Presentation

Software Issues

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Software Issues Derived from Dr. Fawcett’s Slides Phil Pratt-Szeliga Fall 2009

  2. Software Issues:Overview • Definitions • Software Design Objectives Overview • Software Quality • Deal with Complexity • Management of Change • Software Reuse • Design in the Application Domain • Conclusions

  3. Definitions • Unit – Smallest encapsulated piece of processing (function, method, procedure) • Information Cluster – A set of public and private units used for every access to hidden data with: • Complex structure • Sensitive Security • Device Dependence • Class – A pattern for an information cluster providing declarations of types and accessibility of units and data in instances of a class • Object – An instance of a class

  4. Definitions • Module – An implementation of an information cluster • A single file in C#. Two files in C or C++ • Structures functions and data into a public interface and a private implementation • Program – A set of modules which can be compiled and linked into one execution image • Software System – A collection of cooperating programs to achieve some goal • May share data and/or resources

  5. Software Design Objectives • Develop high quality software: • Correct, Robust, Extendible and has reasonable performance • Reuse software components • Use software again without modification • Manage change • When changing one component we want to minimize effects on other components • Deal with complexity • Support a hierarchy of layers and the partitioning of software into relatively independent components

  6. application computer platform compiler source code designer Software Design Objectives • Support Software Design in the Application Domain • Design in terms of processing activities rather than computer activities

  7. Objectives: Software Quality • Correctness • Program exactly performs in accordance to it’s specifications • Robustness • Program can function under abnormal conditions on: Inputs, outputs, data transformations, environment • Extendibility • Program can be adapted to meet other specifications

  8. Objectives: Software Quality • Reusability • Component can be reused without modification for new application • Compatibility • Component can be combined, without modification, with other components • Performance • Use of platform resources and elapsed time to complete task is as small as practical

  9. Software Quality Factors:Assertions • Correctness • Programs should be composed of small, relatively independent, functions and modules • Robustness • Use encapsulation to trap errors and keep them from propagating throughout the system • Extendibility • Compose programs of nearly independent modules which can be augmented with expanded functions and data records

  10. Software Quality Factors:Assertions • Reusability • Implementation details should be hidden behind simple, fixed and easily understood public interfaces • Compatibility • Public interfaces should be well designed, providing standard sockets used to connect to other components • Performance • Increasing modularity often diminishes performance due to overhead of passing data though public interfaces and the invocation of several function call layers

  11. Objectives: Deal with Complexity • A 40 million SLOC operating system such as Windows XP is so complex that not one person can understand the entire thing. • It requires expert knowledge of diverse fields: • Hardware interaction • Protocol standards such as • file systems • networking • media • Window managers • Custom compilers • Process scheduling • Concurrency • Other large systems require knowledge of a complex application domain • For example, medical imaging requires expert knowledge of physics and mathematics and numerical methods

  12. Objectives: Deal with Complexity • Building large systems like an operating system or medical imaging system require consummate knowledge of the application domain and a though understanding of the platform and mastery of powerful but complex tools • That’s the easy part! • The hard part is to conceive, structure, design, implement and test a system so complex that it requires 500 person years to complete and yet achieve conceptual integrity

  13. Dealing with Complexity:Modularity • The purpose of a module or class is to implement a small, simple, logical model • Modularization Purpose: • Build a software system out of cohesive, reliable modules • Modularization consists of dividing a program into modules which can be compiled separately

  14. Objectives: Management of Change • Changes occur in all phases of software development • Analysis • Design • Implementation • Integration • Test • Changes occur due to: • Instability of requirements • Inconsistencies of interfaces • Latent errors in coding • Failure to satisfy performance and functional requirements • With modular design and encapsulation • Changes do not have ripple effects

  15. Objectives: Software Reuse • Hardware reuse has been widely accomplished • Standard integrated circuits: multiplexors, ALUs, processors, memory, … • Standard Boards: processor boards, communication boards • Reuse has not been nearly as successful in the software industry • Reuse: Operating Systems, Compilers, Standard Libraries • Most application code developed from scratch • With Object Oriented Design we can build objects nearly equivalent to software integrated circuits

  16. Objectives: Design in the Application Domain • Modules and Classes model logical behavior of real world entities • Internal complexity is hidden in private implementation • Names and behaviors of modules and classes should be based on: • The application model (top level components) • Specifics of a solution model (bottom level components)

  17. Conclusions • Use modular structure for all but the simplest programs • supports developing correct software • Keep functions and modules small and relatively independent • supports correctness and extensibility • Encapsulate processing details behind public interfaces • supports extensibility and robustness

  18. Conclusions • Make public interfaces as simple and understandable as possible • Supports software reuse • Make the interface conform to some to some abstraction (e.g. sales account) • Choose names of public functions to support the abstraction • Make processing support what a client would expect of the abstraction • Document the public interface in the source code • Supports software reuse

  19. References • Objectives: Software Quality slide adapted from: Object Oriented Software Construction, Bertrand Meyers, Prentice Hall, 1988

More Related