Design Decisions

1. Design Decisions Guest Lecture • Apostolos Ampatzoglou - a.ampatzoglou@rug.nl Software Engineering and Architecture Group http://www.cs.rug.nl/search/People/ApostolosAmpatzoglou

2. Outline • Design Decisions • Software Quality • Examples

3. Design options and decisions A designer is faced with a series of design issues • These are sub-problems of the overall design problem. • Each issue normally has several alternative solutions (or design options) • The designer makes a design decision to resolve each issue. • This process involves choosing the best option from among the alternatives.

4. Design problem sub- problem (or issue) sub- problem (or issue) Decision = best option Design option Design option Design option Design option Decision = best option Alternative solutions Alternative solutions Taking decisions Problem space Decision space

5. fat-client client in a separate user interface layer Programmed in Java client-server client style Programmed in Visual Basic thin-client Programmed in C++ no separate user interface layer monolithic Decision space The space of possible designs that can be achieved by choosing different sets of alternatives.

6. Types of decisions • Implicit, undocumented • Unaware, tacit, of course knowledge • Explicit, undocumented • Vaporizes over time • Explicit, documented • Preferred, exceptional situation

7. Design Documentation • Prevents repeating (expensive) past steps • Explains why this is a good architecture • Emphasizes qualities and criticality for requirements/goals • Provides context and background

8. Elements of a design decision • Issues: design issues being addressed • Decision • Status: e.g., pending, approved • Assumptions: underlying assumptions • Alternatives • Rationale; the why of the decision taken • Implications: e.g. need for further decisions

9. Outline • Design Decisions • Software Quality • Examples

10. Quality an elusive target • Any stakeholder has a different understanding of it and no one can be sure that his/her definition or evaluation method of software quality is adequate • Perspectives on quality • Design-time vs. Run-time • Internal vs. External • Phase of assessment • Granularity • Product vs. Value vs. In Use

11. Design Bad Smells Rigidity: The system is hard to extend, because every change has heavy impact Fragility: Changes in one part of the system causes defects in other parts of the system Immobility: Difficulty to decompose the system to components that can be reused in different software. Viscosity: System is more prone to extension through not optimum extensions mechanism than optimum ones. Needless Complexity: The software includes components that are not or will never become useful. Needless Repetition: The design involves repeated structures that could be merged under a common abstraction. Opacity:Difficulty in understanding a software unit (code or design level).

12. Models, Attributes and Metrics “quality model is a defined set of characteristics, and of relationships between them, which provides a framework for specifying quality requirements and evaluating quality” “quality attribute is a characteristic of software, or a generic term applying to quality factors, quality sub-factors, or metric values” “quality metric is a quantitative measure of the degree to which an item possesses a given quality attribute”

13. Software Quality Models

14. Usually hierarchical

15. What is measurement? "Measurement is the process by which numbers or symbols are assigned to attributes of entities in the real world in such a way as to describe them according to clearly defined rules." [Norman Fenton]

16. Object – Oriented Metrics Chidamber & Kemerer (1991): A suite of OO metrics Many variations Basic Categories: Complexity Coupling Cohesion

17. Complexity • Quantifies the time and effort needed for developing and maintaining the software. • Usually are application specific, hinders reuse • Limited cognition, hinders understandability

18. Cyclomatic Complexity

19. Coupling • high levels hinder reuse • measure of independence • propagation of change • tight vs. loose coupling • type of coupling

20. Coupling Between Objects

21. Cohesion • high cohesion => promotes encapsulation • SRP => indications for splitting the class • related to number of defects

22. Lack of Cohesion of Methods Let a classC with methodsM1, M2, . . ., Mn Let{Ii} the attributes used in Mi. So there are several sets: {Ι1}, {Ι2}, . . . , {Ιn}

23. Outline • Software Quality • Design Decisions • Examples

24. Requirements-1 • A software company that deals with software development and provides technical support • The company employs developers, analysts, managers and technical staff • All employees can be paid by hour or with a monthly salary • The company wishes to develop a system that will calculate the cost of all projects and the expenditures of the company for payroll.

25. Limitations-1 • Cost estimation for software and technical support is calculated by a different algorithm that takes into account the amount of hours that each employee works on the project • Calculating the hourly payment of an employee is easy algorithm. On the other hand, the calculation of salary is more complex, since bonuses per project need to be calculated • Payment units are different across different types of employees

26. Outline • Software Quality • Design Decisions • Examples

27. Requirements-1 • Consider the creation of 3D racing game • In this game the designers would like to present in the main scenes: the cars, the road, and some trees • The car body parts (body, wheels, windows) should animate both autonomously and as a whole • All drawing and animation functions are already implemented in legacy applications

28. Limitations • The designers want the 3D scene to handle all objects interchangeably and uniformly

29. Thank you for your attention