CS8494 Software Engineering

1. CS8494 Software Engineering Name: V R Sathishkumar AP CSE Mohamed Sathak Engineering College

2. Design engineering

3. The goal of design engineering is to produce a model that exhibits: • firmness – a program should not have bugs that inhibit its function; • commodity – a program should be suitable for purposes for which it was intended; • delight – the experience of using the program should be a pleasurable one.

4. Accomplished by practicing diversification and convergence • diversification – acquisition of alternatives (design material, i.e. components, component solutions, knowledge); • convergence – picking and choosing elements from the alternatives that meet the requirements defined by requirements engineering and analysis model.

5. Each of the element of analysis model provide necessary information for the four design models required for design specification: • data/class design; • architectural design; • interface design; • component design.

6. Characteristics that serve as a guide for the evaluation of a good design • The design must implement all of the explicit requirements contained in analysis model and implicit requirements desired by customer. • Design must be readable and understandable by implementers, testers and maintainers alike. • Design should provide complete picture of the software, addressing functional, behavioral and data domains from an implementation perspective.

7. What criteria would help to evaluate design quality?

8. Technical criteria for evaluation of design quality (1) • A design should exhibit an architecture that: • has been created using recognizable architectural styles and patterns; • is composed of components that exhibit good design characteristics; • can be designed in evolutionary fashion.

9. Technical criteria for evaluation of design quality (2) • A design should be modular. • A design should contain distinct representation of data, architecture, interfaces, and components. • A design should lead to data structures that are appropriate for classes to be implemented and are drawn from recognizable patterns. • A design should lead to components that exhibit independent functional characteristics.

10. Technical criteria for evaluation of design quality (3) • A design should lead to interfaces that reduce the complexity of connections between components and with external environment. • A design should be derived using a repeatable method that is driven by information obtained during software requirements analysis. • A design should be represented using a notation that effectively communicates its meaning.

11. Software quality attributes!? Huh?

12. Software quality attributes (FURPS) • Functionality • Usability • Reliability • Performance • Supportability

13. Design concepts “The Beginning of wisdom for a [software engineer] is to recognize the difference between getting a program to work, and getting it right.” M. A. Jackson

14. Abstraction • for modular solution many levels of abstraction can be posed; • at highest level solution is stated in broad terms using language terms of problem environment; • at lower levels a more detailed description is provided; • procedural abstraction refers to a sequence of instructions that have a specific an limited function; • data abstraction is a named collection of data that describes a data object.

15. Architecture (1) • Is the structure/organization of program components (modules), the manner in which these components interact, and the structure of data that is used by the components. • Components can be generalized to represent major system elements and their interactions. • Goal – derive architectural rendering of system, that serves as a framework from which more detailed design activities are conducted.

16. Architecture (2) Architectural design models: • structural models; • framework models; • dynamic models; • process models; • functional models.

17. Patterns • Describes a design structure that solves a particular design problem within a specific context. • Should provide description that enables designer to determine: • whether pattern is applicable to current work; • whether the pattern can be reused; • whether the pattern can serve as a guide for developing similar, but functionally or structurally different pattern.

18. Modularity • Monolithic software cannot be easily grasped by a software engineer. • It takes more time to solve more difficult problem. • “divide an conquer” strategy – it’s easier to solve complex problem when you break it into manageable pieces.

19. Should we subdivide indefinitely?If not how small is too small? ?

20. As the number of modules grows, the effort (cost) associated with integrating the modules also grows!

21. Information hiding • Builds up on modularity concept. • Modules should be specified and designed so that information (algorithms and data) contained within a module is inaccessible to other modules that have no need for such information; • Hiding defines and enforces access constraints to procedural details and local data structures used within a module. • Hiding prevents error propagation outside of a module.

22. Functional independence • Each module should address a specific sub function of requirements and have a simple interface. • Functional independent modules are easier to develop, maintain, and test; • Error propagation is reduced and reusable modules are possible; • Assessed using two qualitative criteria: • cohesion; • coupling.

23. Refinement • A top-down design strategy by which program is designed by successively refining levels of procedural detail; • Abstraction and refinement are complementary features: • one specifies procedure and data without details; • other allows to elaborate by providing low-level details.

24. Refactoring It is the process of changing a software system in such way that it does not alter the external behavior of the code yet improves its internal structure.

25. Design classes Software team must define a set of design classes that: • refine the analysis classes by providing design detail that will enable the classes to be implemented; • create a new set of design classes that implement a software infrastructure to support the business solution.

26. Different types of design classes representing a different layer of design architecture: • user interface classes; • business domain classes; • process classes; • persistent classes; • system classes.

27. What are the characteristics of well formed design classes?

28. Characteristics of well formed design classes • Complete and sufficient • Primitiveness • High cohesion • Low coupling

29. Design model • The elements of design model use many of the same UML diagrams that were used in the analysis model. • The diagrams are refined and elaborated – more implementation specific detail is provided; • Architectural structure and style, components that reside within architecture, interfaces between components and with outside world are all emphasized.

31. Design model elements • Data design elements • Architectural design elements • Interface design elements • The user interface (UI) • External interfaces • Internal interfaces between various design components • Component-level design elements • Deployment-level design elements

32. Types of design patterns considered at various levels of abstraction • Architectural patterns (Peer-to-peer, Service-oriented architecture, etc.) • Design patterns (Iterator, Scheduler, Thread pool, Wrapper, etc.) • Idioms (Infinite loop, swapping values between variables, etc.)

33. Frameworks • Provides an implementation-specific skeletal infrastructure for design work. • It is not a design pattern, but rather a skeleton with a collection of “plug points” that enable it to be adapted to a specific problem domain. • The plug points enable designer to integrate problem specific classes or functionality within the skeleton.