|1
Design Decisions
Guest Lecture
› Apostolos Ampatzoglou - [email protected]
Software Engineering and Architecture Group
http://www.cs.rug.nl/search/People/ApostolosAmpatzoglou
Outline
|2
› Introduction
› Design Decisions
› Software Quality
› Examples
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
[email protected]
Field of Expertize
Software Engineering & Architecture
University of Groningen
|4
Research Group
|5
Research Interest
|6
Research Interest
OO Design
Technical Debt
Game Engineering
Architecting Embedded Systems
Software Quality Assurance
Architectural Knowledge
Research Approach
|7
+
Industry-Driven Research
Solving real problems…
Are the proposed solutions realistic?
Research in Industry
|8
Teaching Approach
|9
Industry-Driven Teaching?
Outline
| 10
› Introduction
› Design Decisions
› Software Quality
› Examples
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.
Taking decisions
12
Problem
space
Design
problem
subproblem
(or issue)
subproblem
(or issue)
Decision =
best option
Design
option
Design
option
Alternative
solutions
Design
option
Alternative
solutions
Design
option
Decision =
best option
Decision
space
Decision space
13
The space of possible designs that can be achieved by
choosing different sets of alternatives.
fat-client
client
style
client-server
client in a
separate
user interface
layer
Programmed in Java
Programmed in Visual Basic
thin-client
Programmed in C++
monolithic
no separate
user interface
layer
Types of decisions
14
› Implicit, undocumented
• Unaware, tacit, of course knowledge
› Explicit, undocumented
• Vaporizes over time
› Explicit, documented
• Preferred, exceptional situation
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
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
Outline
| 17
› Introduction
› Design Decisions
› Software Quality
› Examples
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
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).
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”
Software Quality Models
Usually hierarchical
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]
Object – Oriented Metrics
Chidamber & Kemerer (1991): A suite of OO metrics
Many variations
Basic Categories:
Complexity
Coupling
Cohesion
Complexity
› Quantifies the time and effort needed for developing and
maintaining the software.
› Usually are application specific, hinders reuse
› Limited cognition, hinders understandability
Cyclomatic Complexity
Coupling
› high levels hinder reuse
› measure of independence
› propagation of change
• tight vs. loose coupling
› type of coupling
Coupling Between Objects
Cohesion
› high cohesion => promotes encapsulation
› SRP => indications for splitting the class
› related to number of defects
Lack of Cohesion of Methods
Let a class C with methods M1, M2, . . ., Mn
Let {Ii} the attributes used in Mi.
So there are several sets: {Ι1}, {Ι2}, . . . , {Ιn}
P  {I i , I j  | I i  I j  
Q  {I i , I j  | I i  I j  
LCOM 
PQ
if P  Q
0
otherwise
Outline
| 31
› Introduction
› Software Quality
› Design Decisions
› Examples
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.
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
Outline
| 34
› Introduction
› Software Quality
› Design Decisions
› Examples
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
Limitations
› The designers want the 3D scene to handle all objects
interchangeably and uniformly
| 37
Thank you for your attention