‫מרצים‪ :‬דני אלמוג‪ ,‬הדס חסידים‬

‫תשע"ח‬
‫באר שבע יום א ‪10:00 – 13:00‬‬
‫‪17:00 - 14:00‬‬
‫אשדוד יום ב ‪11:00 – 14:00‬‬

‫שעות קבלה‪ :‬בתאום מראש‬

‫דואל‪hadasch@ac.sce.ac.il almog.dani@gmail.com :‬‬
‫‪1‬‬
 ‫פעילויות למידה מתוכננות ושיטות הוראה‬
‫לקורס הוגדרו מקורות מהם ניתן להרחיב את ההבנה בחומרים הנלמדים‪ .‬במפגשים הפרונטליים ישתתפו הסטודנטים‬
‫בהצגת ותרגול החומרים הנלמדים‪ .‬על הסטודנטים להכין עצמם עם חומרי הלימוד לפני השיעור‪.‬‬
‫הגשת החומרים (תרגול ועבודת חקר) הינה בזוגות או יחידים (לא שלשות)‪ .‬יש להירשם אצל המתרגלים עד לאחר‬
‫התרגול הראשון‪ .‬מי שלא ירשם עד אז ישובץ באופן שרירותי על ידי המתרגל‪ .‬בסוף הסמסטר יתקיים האקטון בדיקות‪.‬‬
‫לקורס אתר ב ‪ Moodle‬ובאמצעותו יוגשו כל התרגילים והעבודות‪.‬‬
‫שיטות הערכה וקריטריונים‬
‫לבחינה ‪ 2‬חלקים (שאלות המציגות הבנה והפנמת החומר ו שאלות הבוחנות יכולת‬ ‫בחינה סופית‪]60%[ :‬‬
‫אינטגרציה ומימוש של החומר הנלמד על בעיה אמתית) – חובת מעבר לבחינה‬
‫השתתפות חובה בשעורי התרגול והגשת כל התרגילים ציון התרגול ייחשב רק באם‬ ‫תרגילי בית‪]40%[ :‬‬
‫עברת את הבחינה הסופית‪( 10%=5%*2 .‬תרגיל קטן); ‪( 20%=10%*2‬תרגיל גדול); ‪ 10%‬האקטון בדיקות‬
‫הסעיף הינו בחירה כבונוס (הקטנת משקל הבחינה ל ‪)50%‬‬ ‫עבודת חקר‪]10%[ :‬‬
‫נוכחות‪ :‬נוכחות חובה ב‪ 70%‬מהשעורים (‪ 8‬מפגשים) כל העדרות מעבר לכך‪ ,‬משמעה הורדה של ‪ 5%‬מהציון הסופי‬
‫(על כל שעור שהוחסר)‪ ,‬נוכחות חובה בכל שעורי התרגול‪.‬‬
‫‪2‬‬
 ‫ניתן להבטיח ‪ 10%‬מהציון הסופי של הקורס באמצעות הגשת עבודה לתיבת ההגשה במודל‪.‬‬
‫להלן הדרישות לעבודה‪:‬‬
‫‪ ‬העבודה הינה מחקר ספרות למונח ‪ mobile testing‬בתוספת למה שהוגדר בשעורים ראה הגדרה באתר‬
‫הקורס‪.‬‬
‫‪ ‬העבודה תכתב באנגלית‬
‫‪ ‬מטרת המחקר לענות על השאלה – ‪ what is a mobile testing‬התשובה תכלול טבלה עם הפרטים הבאים‪:‬‬
‫‪ ‬טכניקות לבדיקות מובייל‬
‫‪ ‬לאיזה סוגי בדיקות מתייחס‬
‫‪ ‬יתרונות‬
‫‪ ‬חסרונות‬
‫‪ ‬מקורות אקדמיים על פי הם התבססו (לפחות ‪ 3‬מקורות אקדמיים שונים‪ ,‬עדכניים לפחות מ ‪.)2010‬‬
‫‪ ‬על כל צוות לקבל מהמרצה אישור מוקדם למקורות האקדמיים (עד תאריך – לפני ה ‪ 19‬דצמבר)‬
‫‪ ‬תאריך הגשה סופי‪10-1-18 :‬‬
‫‪ ‬ניתן להגיש את העבודה בזוגות או ביחידים‪ .‬יש להודיע עד ‪ 6.11‬מי מעוניין –שמות המגיש\ים‪.‬‬
‫‪3‬‬
‫למי שיעמוד בקריטריונים להגשה יוענקו ‪ 10‬נקודות לציון הסופי ומשקל הבחינה בציון הקורס יירד ל ‪50%‬‬
 ‫מקורות‬ ‫שבוע נושא‬
‫רלוונטיים‬
‫‪1‬‬ ‫מבוא‪ ,‬מהי איכות תוכנה‪ ,‬איכות תוכנה במחזור חיי תוכנה‬ ‫‪1‬‬
‫‪1,2‬‬ ‫מדדי איכות של תוכנה‪ ,‬מה לומדים מהקוד‪,‬‬ ‫‪2‬‬
‫‪7,9‬‬ ‫האורקל של הבדיקות‪ ,‬בדיקות בתהליך הקידוד (‪,)unit test‬פיתוח בדיקות )מסיפור משתמש למקרה הבדיקה)‬ ‫‪3‬‬
‫‪1,2,3‬‬ ‫סוגי בדיקות השונים‪ -‬פונקציונאליות‬ ‫‪4‬‬
‫‪4‬‬ ‫אזורי בדיקה טכניקות ומיפוי‪-‬שקילות‪ ,‬גבולות‬ ‫‪5‬‬
‫‪4‬‬ ‫המשך טכניקות בדיקה‪ -‬מונחה סיכונים ודרישות‬ ‫‪6‬‬
‫‪13‬‬ ‫שיטות לבחירת מקרי ותכולת הבדיקות‪Model Driven Testing ,‬‬ ‫‪7‬‬
‫‪ testability‬עקיבות‪ ,‬דרגות הבדיקה‪ ,‬ניהול שגויים‬ ‫‪8‬‬
‫פיתוח וניהול תוכנית איכות ובדיקות‬ ‫‪9‬‬
‫סביבות בדיקה (בסיסי נתונים‪ ,‬מכונות וירטואליות‪ ,‬כלי בדיקה)‬ ‫‪10‬‬

‫‪11,12,14‬‬ ‫שיטות פיתוח ובדיקות בסביבות מתקדמות‪IoT ,Mobile DevOps -‬‬ ‫‪11‬‬

‫‪4‬‬ ‫הצד האנושי היבטים רכים –תפקידים‪ ,‬תקשורת‪ ,‬יכולות‬ ‫‪12‬‬

‫שעור חזרה והכנה לבחינה‬ ‫‪13‬‬
‫‪4‬‬
 ‫מה יהיה בשיעור זה‬
‫מה היה בשיעור‬
‫‪ ‬תזכורת – איכות ומודלי חיים‬ ‫הקודם‬
‫‪ ‬מדדי איכות של תוכנה –‬
‫‪4 .Software Quality measurements‬‬ ‫• בדקנו האם אנו מצוידים היום‬
‫‪ ‬מה לומדים מהקוד –‬ ‫להגדיר בדיקות של מוצרים לפני‬
‫הפצתם (מדיח כלים במטבח)‬
‫?‪5.What can we learn from the code‬‬
‫‪ ‬אתגרי הסיבוכיות והמורכבות –‬ ‫• נכנסנו להגדרות של מהי‬
‫איכות ובכלל ומהי איכות תוכנה‬
‫‪6. Challenges and complexity - looking at the code‬‬
‫‪ ‬זרימה והתנהלות הקוד – יועבר בעיקר בתרגול‬ ‫• חזרנו על מחזור החיים של‬
‫תוכנה‬
‫‪7. Flow and other control charts derived from the code‬‬
‫• חזרנו על מודלי מחזור החיים‬
‫השונים של התוכנה‬
‫• מפל מים ו ‪V‬‬
‫• איטרציה מעגלית – ספירלה‬
‫• מודלים אג'יליים‬
‫‪ • 5‬מודל ה ‪KanBan‬‬
6
 ‫נזכר בסקראם‬

Image available at www.mountaingoatsoftware.com/scrum

7
Both Kanban and Scrum focus on releasing software early and often. Both require highly-
collaborative and self-managed teams. There are, however, differences between the approaches:

Scrum KanBan
Pre-defined roles of Scrum master, Product owner and team No prescribed roles
member
Timeboxed sprints Timeboxed sprints
Work is pulled through the system in batches (the sprint Work is pulled through the system (single piece flow)
backlog)
No changes allowed mid-sprint Changes can be made at any time
Velocity Cycle time
More appropriate in situations where work can be prioritized More appropriate in operational environments with a
in batches that can be left alone high degree of variability in priority
8
4.1 Software Quality Measurements buildup processes
4.2 Static /Dynamic code analysis

9
These four terms are often used interchangeably, but they can have
subtle differences
 Measure
Provides a quantitative indication of the extent, amount,
dimension, capacity, or size of some attribute of a product
or process
 Measurement
The act of determining a measure
 Metric
(IEEE) A quantitative measure of the degree to which a
system, component, or process possesses a given attribute
 Indicator
A metric or combination of metrics that provides insight into
the software process, a software project, or the product
itself
10
 Formulation
 The derivation (i.e., identification) of software measures and metrics appropriate for the
representation of the software that is being considered
 Collection
 The mechanism used to accumulate data required to derive the formulated metrics

 Analysis
 The computation of metrics and the application of mathematical tools

 Interpretation
 The evaluation of metrics in an effort to gain insight into the quality of the representation

 Feedback
 Recommendations derived from the interpretation of product metrics and passed on to the
software development team
11
 Simple and computable
 It should be relatively easy to learn how to derive the metric, and its computation should not demand
inordinate effort or time
 Empirically and intuitively persuasive
 The metric should satisfy the engineer’s intuitive notions about the product attribute under
consideration
 Consistent and objective
 The metric should always yield results that are unambiguous

 Consistent in the use of units and dimensions

 The mathematical computation of the metric should use measures that do not lead to bizarre
combinations of units
 Programming language independent
 Metrics should be based on the analysis model, the design model, or the structure of the program
itself
 An effective mechanism for high-quality feedback
 The metric should lead to a higher-quality end product 12
13
 To meet Tracking & Are we testing
client Controlling rightly?
expectations phases

When to stop
testing? Is the testing
efficient

Have we caught
Trend sufficient
Analysis defects

Is the End users

system Improvements & perspective
ready for Optimization
release? 14
 ‫תקן מרכז‬
A look at ISO Standards?
‫תתי תקנים‬
)‫(סעיפי תקן‬

‫יחידות בסיס‬
‫לאיסוף‬

Taken from:
An Information Model for Software Quality Measurement with ISO Standards - Alain Abran Et. Al 15
 Quality attributes division

Taken from:
An Information Model for Software Quality Measurement with ISO Standards - Alain Abran Et. Al
16
ISO/IEC/IEEE 29119 Software Testing is an internationally agreed set of standards for
software testing that can be used within any software development life cycle or
organisation. By implementing these standards, you will be adopting the only
internationally-recognised and agreed standards for software testing, which will provide
your organisation with a high-quality approach to testing that can be communicated
throughout the world. There are currently five standards:
•ISO/IEC 29119-1: Concepts & Definitions (published September 2013)
•ISO/IEC 29119-2: Test Processes (published September 2013)
•ISO/IEC 29119-3: Test Documentation (published September 2013)
•ISO/IEC 29119-4: Test Techniques (at DIS stage)
•ISO/IEC 29119-5: Keyword Driven Testing (at WD stage)
Plus, based on the processes defined in ISO/IEC/IEEE 29119-2:
•ISO/IEC 33063: Process Assessment Model (at DIS stage)

17
 Testing Techniques
Specification-Based Structure-Based Experience-Based
Equivalence Partitioning Statement Testing Error Guessing
Classification Tree Method Branch Testing Exploratory
Boundary Value Analysis Decision Testing Checklist based
State Transition Testing Condition Testing Attacks
Decision Table Testing Data Flow Testing
Cause-Effect Graphing
Syntax Testing
Combinatorial Test
Scenario Testing (including
Use Case Testing)
Random Testing
18
At least two out of the five statements, but possibly more A[] B[]
than two share equivalents of the meaning:
 Establish software quality requirements
 Mark the only statements that share equivalent
meaning  Identify software quality metrics
 Explain briefly the reason you have selected these  Implement the software quality metrics
items  Analyze the software metrics results
 Validate the software quality metrics

C [] D [x] E [x ]
Measure - Provides a quantitative indication of
the extent, amount, dimension, capacity
Measurement - determining a measure
Metric - A quantitative measure of the degree to
which a system, component,
Indicator - A metric or combination of metrics
that provide insight into the software, product,
project

19
 Static analysis is performed in a non-runtime environment. Typically a
static analysis tool will inspect program code for all possible run-time
behaviors and seek out coding flaws, back doors, and potentially
malicious code.
 Dynamic analysis adopts the opposite approach and is executed while a
program is in operation. A dynamic test will monitor system memory,
functional behavior, response time, and overall performance of the
system. This method is not wholly dissimilar to the manner in which a
malicious third party may interact with an application. Having originated
and evolved separately, static and dynamic analysis have, at times, been
mistakenly viewed in opposition
20
Static analysis, with its white box visibility, is certainly the Static code analysis is done
more thorough approach and may also prove more cost- without executing any of the
code;
efficient with the ability to detect bugs at an early phase of dynamic code analysis relies
the software development life cycle. For example, if an error is on studying how the code
spotted at a review meeting or a desk-check. Had the error behaves during execution.
become lodged in the system, costs would multiply. Static
Code
analysis can also unearth future errors that would not emerge
in a dynamic test. Analyze
Dynamic analysis, on the other hand, is capable of exposing a
subtle flaw or vulnerability too complicated for static analysis instrument
alone to reveal and can also be the more expedient method of
Execute
testing. A dynamic test, however, will only find defects in the
part of the code that is actually executed. Analyze
21
At least two out of the five statements, but possibly
more than two share equivalents of the meaning:
 Mark the only statements that share equivalent
meaning
 Explain briefly the reason you have selected these
items
C[]
Static analysis tools should be used when
they help maintain code quality. If they're
used, they should be integrated into the build
process, otherwise they will be ignored.
A[] B [ x]
Analyzing code without executing it.
Generally used to find bugs or ensure
conformance to coding guidelines or other
specification given to the tool
D[] E [x ]
A software verification activity in which
source code is analyzed for quality, safety,
and security. This analysis enables software
developers and testers to identify and
diagnose various types of bugs/errors such as
overflows, divide by zero, memory and
pointer errors, run-time errors ..
22
5.1 Structural code design Principles
5.2 Naming conventions rules - how to identify issues
5.3 Measurement and entities in OO programs

23
 Procedural programming is a programming paradigm, derived from structured programming, based
upon the concept of the procedure call. Procedures, also known as routines, subroutines, or functions
(not to be confused with mathematical functions, but similar to those used in functional programming),
simply contain a series of computational steps to be carried out. Any given procedure might be called at
any point during a program's execution, including by other procedures or itself.

Code  Pascal
 Fortran
Compile
 Cobol
Traditional procedural programming is far less
link C
dogmatic: you have data. You have functions.
You apply the functions to the data. If you want  Ada
to organize your program somehow, that's your Execute
problem, and the language really isn't going to  Go
help you
24
 Programming paradigm aimed on improving the clarity, quality, and
development time of a computer program by making extensive use
of subroutines, block structures and for and while loops—in contrast to
using simple tests and jumps such as the goto statement which could
lead to "spaghetti code" which is both difficult to follow and to maintain.

25
 ‫בדרך כלל מכילה הסתכלות ותכנון מלמעלה למטה ( ‪ ) Top down‬כאשר‬
‫המפתח מגדיר סט של רוטינות ופונקציות המקודדות בנפרד שמשמעותו שהקוד‬
‫יכול להיות מועמס לתוך הזיכרון בצורה יעילה והשימוש החוזר ברוטינות אלו‬
‫הוא חלק חשוב בעיצוב התוכנה‪ .‬עיצוב שכזה מקל על בדיקת הקוד כל רוטינה‬
‫בנפרד ( ‪ ) Unit Test‬והאינטגרציה ביניהם כתהליך בדיקה עצמאי‬

‫‪26‬‬
At least two out of the five statements, but possibly
more than two share equivalents of the meaning:
 Mark the only statements that share equivalent
meaning
 Explain briefly the reason you have selected these
items
C [ x]
A [x ]
Structured programming frequently employs
a top-down design model, in which
developers map out the overall program
structure into separate subsections
D[]
B[]
Programming paradigm aimed on improving
the clarity, quality, and development time of
a computer program by making extensive use
of subroutines, block
structures and for and while loops
E [x ]
27
Naming convention is a set of rules for choosing the character sequence
to be used for identifiers which denote variables, types, functions, and
other entities in source code and documentation.
CamelCase is the practice of writing compound words or phrases in which
Elements that influence most if the words are joined without spaces and are capitalized within the
not all naming conventions in compound like BreakFast, myName etc. CamelCase is so named because
each word in the identifier is put together without spaces, but with the first
common use today.
letter of each word captilised, looking like humps of a camel. There are two
 Length of identifiers
varieties in CamelCase- UpperCamelCase and lowerCamelCase. In java
 Letter case and numerals
variables, references, method names are declared in lowerCamelCase.
 Multiple-word identifiers
 Delimiter-separated words
if (one_of_our_conditions_is_true())
 Letter-case separated words
{
call_one_of_our_functions();
CallSystemFunction(); 28
}
 Do use PascalCasing for class names and method
names.
Why: consistent with the Microsoft's .NET
Framework and easy to read.
Do use camelCasing for method arguments and
local variables.
Why: consistent with the Microsoft's .NET
Framework and easy to read.
Do not use Hungarian notation or any other type
identification in identifiers
Why: consistent with the Microsoft's .NET
Framework and Visual Studio IDE makes determining
types very easy (via tooltips).
Do not use Screaming Caps for constants or
readonly variables
Why: consistent with the Microsoft's .NET
Framework. Caps grap too much attention
Avoid using Abbreviations. Exceptions: abbreviations
commonly used as names, such as Id, Xml, Ftp, Url
Why: consistent with the Microsoft's .NET Framework
and prevents inconsistent abbreviations.
Do use: PascalCasing for abbreviations 3 characters or
more (2 chars are both uppercase)
Why: consistent with the Microsoft's .NET Framework.
Caps would grap visually too much attention.
Do not use Underscores in identifiers. Exception: you can
prefix private static variables with an underscore.
Why: consistent with the Microsoft's .NET Framework
and makes code more natural to read (without 'slur').
Also avoids underline stress (inability to see underline).
29
At least two out of the five statements, but possibly
more than two share equivalents of the meaning:
 Mark the only statements that share equivalent
meaning
 Explain briefly the reason you have selected these
items
C [x ]
A[]
A set of rules for choosing the character
sequence to be used for identifiers which
denote variables, types, functions, and other
entities in source code and documentation.
D[]
Create uniform coding habits among
software personnel in the engineering
department so that reading, checking, and
maintaining code written by different
persons becomes easier.
B[]
E [ x]
CamelCase; also known as camel caps or
more formally as medial capitals) is the
practice of writing compound words or
phrases such that each word or abbreviation
in the middle of the phrase begins with a
capital letter, with no intervening spaces or
punctuation
30
 In a procedural program, modules interact by reading and writing state that is
stored in shared data structures.

In an object oriented program, modules in the form of objects interact by sending

messages to other objects

In a procedural program, the code is king and the data is subordinate. In other
words, you have programs which act on data and they're not usually tightly bound.

In the OO world, objects are the primary thing of interest. An object consists of data
and the code that is allowed to act on that data, and they are very tightly bound. It
is the concept of encapsulation, the hiding of information.
http://stackoverflow.com/questions/530741/whats-the-difference-between-a-procedural-program-and-an-object-oriented-program 31
Object-oriented design and development are popular
concepts in today's software development
environment.
Object oriented development requires not only a
different approach to design and implementation, it
requires a different approach to software metrics.
Thus, the approach to software metrics for object
oriented programs must be different from the
standard metrics set. 32
There are several main types of OO metrics:
 Coupling Metrics
 Cohesion Metrics
 Inheritance related measures

Object A
Object D
Shared
Inherited Object B
Parameters
from
Object C
33
Coupling metrics are the counts of interactions between
classes
Main metrics:
 CBO (coupling between object classes)
For a class, is defined as the number of other classes to which it is
coupled.
 RFC (response set for class(
The number of methods in the set of all methods that can be
invoked in response to a message sent to an object of a class.
34
 Class 2DPoint

 {
‫שאלה‬
‫כמה‬
RFC (response set for class(
 private int x;
? ‫יש בקוד שאנחנו רואים‬
 private int y;
 public 2DPoint(int x,int y){
 this.x = x; The only method that can be invoked
as a result of a method invocation is :
 this.y = y; }
dinstanceFromOrigin. Thus, RFC = 1.
 public distance(int x1,int y1){
 return Math.sqrt(Math.pow((x-x1),2) + Math.pow((y-y1),2)); }
 public dinstanceFromOrigin(){
 return this.distance(0,0); }
 }

35
Cohesion metrics measure how well the methods of a class are related to each
other.
Main metrics:
 LCOM (Lack of Cohesion)
Measures the dissimilarity of methods in a class by instance
variable or attributes.
 TCC (tight class cohesion(
Ratio of number of similar method pairs to total number of method pairs in the class.
NP = maximum number of possible connections.
NDC = number of direct connections.
TCC = NDC/NP.
TCC<0.5 considered non-cohesive classes.

36
Main metrics:
 DIT (depth of inheritance tree)
Maximum inheritance path from the class to the root class.
The deeper a class is in the hierarchy, the more methods and variables it is likely to
inherit, making it more complex.
 NOC (number of children)
Number of immediate sub-classes of a class.
NOC measures the breadth of a class hierarchy, where DIT measures the depth.
Depth is generally better than breadth, since it promotes reuse of methods
through inheritance.
High NOC has been found to indicate fewer faults.
This may be due to high reuse, which is desirable. 37
At least two out of the five statements, but possibly
more than two share equivalents of the meaning:
 Mark the only statements that share equivalent
meaning
 Explain briefly the reason you have selected these
items
A[] B [x ]
With OO software code quality measurement Shared variables or control information
have become more complex and sophisticate
exchange lead to tight coupling.
since new relation and affiliations are introduced
– also the dynamic nature of execution makes it
even harder to estimate the possible impact of
each measurement.

C[] D [ x] E[]
Modular decomposability; Coupling Metrics
Modular composability;
Modular understandability; Cohesion Metrics
Modular continuity;
Inheritance related measures
Modular protection.

38
6.1 What is Cyclometic complexity
6.2 Complexity in OO code
6.3 Challenges and complexity in Microservices architecture

39
 ?‫מה עוד‬ )‫כמה (בואו נספור‬
)‫ (מקייב מסבך לנו את החיים‬Complexity ‫ סיבוכיות‬ LOC- line of code 
Cyclomatic complexity  ‫מספר ההתפצלויות‬ 
Reachability 
# of object declared in source file 
Looping depth 
# of class declared in source file 
‫ מתאים לסטנדרט‬ tested
‫ מובנה‬ ‫אובייקטים כלולים בכל קלאס מוצהר‬ 
‫ מכסה‬ Data members in a class 
‫ תיעוד פנימי‬ ? ‫הצעות נוספות‬ 

40
 ‫מה מציעים לנו לסקור בקוד‬
:‫) מציע לנו לשאול עצמנו לסיכום הבדיקה‬Glenford J. Myers( ‫מאיירס‬
 Was the program easy to understand?
 Was the high-level design visible and reasonable?
‫ בספר (אומנות בדיקות‬3.2 ‫ ו‬3.1 ‫בטבלאות‬
 Was the low-level design visible and reasonable? ‫התוכנה) ישנה רשימה חלקית של בעיות‬
)‫ סוגי תקלות‬50 ‫שניתן לזהות בקוד ( כ‬
 Would it be easy for you to modify this program?
 Would you be proud to have written this program?

‫להשתמש בטכניקות הבאות לשם התמודדות עם הקוד‬

 Code inspections using checklists
 Group walkthroughs
 Desk checking
 Peer reviews
 I say – find software to do the job! 41
Software primitives - ‫מבנים בסיסים בתוכנה‬

42
 Cyclomatic Complexity – ‫סיבוכיות סיבובית‬
Cyclomatic Complexity reflects the decision-making structure of the program. It is
recommended that for any given module the metric should not exceed ten. This value should
be used as an indicator of modules which may benefit from redesign. It is a measure of the
size of the directed graph,
e – )edges( ‫קשתות‬
n - )vertices( ‫קודקודים‬ I) v(G)~l.
p - ‫רכיבים מחוברים‬ 2) v(G) is the maximum number of linearly independent
Definition 1: The cyclomatic number paths in G; it is the size of a basis set.
V(G) of a graph G with n vertices, e 3) Inserting or deleting functional statements to G does not affect v(G).
edges, and p connected components is: 4) G has only one path if and only if v(G) = I.
5) Inserting a new edge in G increases v(G) by unity.
v(G) = e - n + p 6) v(G) depends only on the decision structure of G.

43
‫סיבוכיות בהגדרה שונה‬

‫‪44‬‬
‫הקשר בין מורכבות לכמות הבאגים‬

‫‪45‬‬
At least two out of the five statements, but possibly A[] B [x ]
more than two share equivalents of the meaning: It is a software metric (measurement), used
 Mark the only statements that share equivalent
meaning
to indicate the complexity of a program. It is
 Explain briefly the reason you have selected these a quantitative measure of the number of
items linearly independent paths through a
program's source code

C[]
Graph: Usually the control flow graph (CFG)
Node coverage: Execute every statement
Edge coverage: Execute every branch
Loops: Looping structures such as for loops,
while loops, etc.
Data flow coverage: Augment the CFG
D [x ]
The Cyclomatic number V(G) of a graph G
with n vertices, e edges, and p connected
components is calculated by:
v(G) = e -n + p.
E[]
v(G) is the maximum number of linearly
independent paths in G; it is the size of a basis set.
Inserting or deleting functional statements to G
does not affect v(G).
G has only one path if and only if v(G) = I.
Inserting a new edge in G increases v(G) by unity.
v(G) depends only on the decision structure of G.

46
Fan-in = number of ingoing dependencies
Fan-out = number of outgoing dependencies

Heuristic: a high fan-in/fan-out indicates a high complexity

47
Before After

48
 Client
classes
Façade

Note the effect on the fan-in/coupling of the component

49
At least two out of the five statements, but possibly A[] B[]
more than two share equivalents of the meaning: characteristics that impact testing
 Mark the only statements that share equivalent
meaning
State dependent behavior
 Explain briefly the reason you have selected these Encapsulation
items Inheritance
Polymorphism and dynamic binding
Abstract and generic classes
Exception handling
C[] D[] E[]
Declaration graph WMC: Weighted Methods per Class Two classes are coupled if a method of one
Call graph DIT: Depth of Inheritance Tree class uses a method or state variable of
Hierarchical Graph NOC: Number Of Children another class
Inherent depth CBO: Coupling Between Object Classes CBO = count of all classes a given class is
No. of children RFC: Response For a Class coupled with
LCOM: Lack of COhesion of a Method High values: something is wrong

50
 Many smaller (fine grained), clearly scoped
services
 Single Responsibility Principle
 Domain Driven Development
 Bounded Context
 Independently Managed
 Clear ownership for each service
Attribution: Adrian Cockroft, Martin Fowler … 51
Monolithic Microservices

Internal (Nodes = 9 , Arks = 12) Nodes = 13 , Arks = 22

52
At least two out of the five statements, but possibly
more than two share equivalents of the meaning:
 Mark the only statements that share equivalent
meaning
 Explain briefly the reason you have selected these
items
C[]
highly granular nature can lead to a great
deal of complexity in composing applications.
Highly focused components can force service
consumers to become more involved in the
internals of an interaction than they might
otherwise wish
A [x ]
D[]
Microservices architecture allows us moving
complexity into the area where we know how
to automate things. We have learned a lot in
the past decades about automation of
systems operations
B [x ]
Many small moving parts are not inherently
more manageable than one huge organism.
Indeed, while the individual complexity of a
microservice may be reduced, the
sophistication of orchestrating a large,
distributed system is significant.
E[]
Microservices imply a distributed system. Where
before we might have had a method call acting as
a subsystem boundary, we now introduce lots of
remote procedure calls, REST APIs or messaging
to glue components together across different
processes and servers
53
 ‫מה היה בשיעור זה‬
‫מה להתכונן‬
‫‪ ‬מדדי איכות של תוכנה –‬
‫לשיעור הבא‬
‫‪4 .Software Quality measurements‬‬ ‫‪ o‬האורקל של הבדיקות‬
‫‪ ‬מה לומדים מהקוד –‬ ‫‪ o‬בדיקות יחידה‬
‫?‪5.What can we learn from the code‬‬
‫‪ ‬אתגרי הסיבוכיות והמורכבות –‬
‫‪6. Challenges and complexity - looking at the code‬‬
‫‪ ‬זרימה והתנהלות הקוד – יועבר בתרגול הקרוב‬
‫‪7. Flow and other control charts derived from the code‬‬

‫‪66‬‬
‫להתראות בשבוע הבא‬

‫‪67‬‬