Design Decisions. Guest Lecture

Transcription

1 1 Design Decisions Guest Lecture Apostolos Ampatzoglou - a.ampatzoglou@rug.nl Software Engineering and Architecture Group

2 Outline 2 Introduction Design Decisions Software Quality Examples

3 Info for the Lecturer 3 dr. Apostolos Ampatzoglou Adjacent Assistant Professor, Software Engineering/Architecture, University of Groningen, Netherlands Adjacent Assistant Professor, International Hellenic University, Thessaloniki, Greece Adjacent Lecturer, Department of Informatics & Telecommunication Engineers, Kozani, Greece Contact a.ampatzoglou@rug.nl Field of Expertize Software Engineering & Architecture

4 City/University of Groningen 4

5 Research Group 5

6 Research Interest 6 Research Interest OO Design Technical Debt Game Engineering Architecting Embedded Systems Software Quality Assurance Architectural Knowledge

7 Research Approach 7 + Industry-Driven Research Solving real problems Are the proposed solutions realistic?

8 Research in Industry 8

9 Teaching Approach 9 Industry-Driven Teaching?

10 Outline 10 Introduction Design Decisions Software Quality Examples

11 Design options and decisions 11 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.

12 Taking decisions Problem space 12 Decision space

13 Decision space The space of possible designs that can be achieved by choosing different sets of alternatives. 13

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

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

16 Elements of a design decision 16 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

17 Outline 17 Introduction Design Decisions Software Quality Examples

18 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

19 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).

20 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

21 Software Quality Models

22 Usually hierarchical

23 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]

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

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

26 Cyclomatic Complexity

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

28 Coupling Between Objects

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

30 Lack of Cohesion of Methods otherwise Q P if Q P LCOM I I I I Q I I I I P j i j i j i j i 0, {, { Let a class C with methods M 1, M 2,..., M n Let {I i } the attributes used in M i. So there are several sets: {Ι 1 }, {Ι 2 },..., {Ι n }

31 Outline 31 Introduction Software Quality Design Decisions Examples

32 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.

33 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

34 Outline 34 Introduction Software Quality Design Decisions Examples

35 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

36 Limitations The designers want the 3D scene to handle all objects interchangeably and uniformly

37 Thank you for your attention 37