0% found this document useful (0 votes)
39 views63 pages

Cursul 5 - 19 Martie 2018 Adiftene@info - Uaic

This principle aims to reduce coupling between classes.

Uploaded by

Cristian Iacob
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
39 views63 pages

Cursul 5 - 19 Martie 2018 Adiftene@info - Uaic

This principle aims to reduce coupling between classes.

Uploaded by

Cristian Iacob
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 63

Cursul 5 – 19 Martie 2018

[email protected]

1
 Din Cursurile trecute…
 Forward and Reverse Engineering
 GRASP
◦ Information Expert
◦ Creator
◦ Low coupling
◦ High cohesion
◦ Controller

2
 Săptămâna 7-a e termenul limită pentru
alegerea proiectului

 După care urmează: documentare, înțelegere,


knowledge transfer, diagrame use case,
diagrame de clasă, implementare, unit testing,
etc.

 Săptămâna a 7-a începe efectiv lucrul la proiect,


iar evaluarea se încheie în săptămâna a 14-a

 În săptămâna a 8-a nu se fac ore…


3
 De ce avem nevoie de modelare?

 Cum putem modela un proiect?

 SCRUM – roles, values, artifacts, events, rules

4
5
 A traditional process of moving from high-level
abstractions and logical to the implementation-
independent designs to the physical
implementation of a system

 FE follows a sequence of going from requirements


through designing its implementation

6
 Reverse engineering (RE) is the process of
discovering the technological principles of a
device, object or system through analysis of its
structure, function and operation
 To try to make a new device or program that
does the same thing without copying anything
from the original
 Reverse engineering has its origins in the
analysis of hardware for commercial or military
advantage

7
 Interoperability
 Lost documentation
 Product analysis
 Security auditing
 Removal of copy protection, circumvention of access
restrictions
 Creation of unlicensed/unapproved duplicates
 Academic/learning purposes
 Curiosity
 Competitive technical intelligence (understand what
your competitor is actually doing versus what they
say they are doing)
 Learning: Learn from others mistakes
8
 RE1: Reverse engineering of mechanical devices
 RE2: Reverse engineering of integrated
circuits/smart cards
 RE3: Reverse engineering for military
applications
 RE4: Reverse engineering of software

9
10
11
 Rapid prototyping

 FullCure materials

12
13
14
 RE is an invasive and destructive form of
analyzing a smart card

 The attacker grinds away layer by layer of the


smart card and takes pictures with an electron
microscope

 Engineers employ sensors to detect and prevent


this attack

15
16
17
 Satellite TV
 Security card
 Phone card
 Ticket card
 Bank card

18
 Reverse engineering is often used by militaries in
order to copy other nations' technologies, devices or
information that have been obtained by regular
troops in the fields or by intelligence operations

 It was often used during the Second World War and


the Cold War

 Well-known examples from WWII and later include:


rocket, missile, bombers, China has reversed many
examples of US and Russian hardware, from fighter
aircraft to missiles and HMMWV cars
19
 US – B-29 URSS – Tupolev Tu-4

20
 Chinese J-20, Black Eagle US F-22, Russian Sukhoi T-50

21
 US -AIM-9 Sidewinder Soviet - Vympel K-13

22
23
24
 Reverse engineering is the process of analyzing
a subject system to create representations of the
system at a higher level of abstraction

 In practice, two main types of RE emerge:


◦ Source code is available (but it is poorly documented)
◦ There is no source code available for the software

 Black box testing in software engineering has a


lot in common with reverse engineering

25
26
27
public class Test
{
private int n;
private int m;

public static void main(String


args[])
{
for(int i=1;i<10;i++)
System.out.println("Test");
}
}

28
 Link: http://www.steike.com/code/java-reverse-
engineering/
 jad.exe NumeFisier.class => NumeFisier.jad

29
30
31
 File -> Import Sources...

32
33
 Forward engineering:
◦ Diagrame de clasă -> .java files (ArgoUML)
◦ .java files -> .class files (NetBeans)

 Reverse engineering:
◦ .class files -> .java files (JAD Decompiler)
◦ .java files -> Diagrame de Clasă (ArgoUML)

34
 GRASP = General Responsibility Assignement
Software Patterns (Principles)
 Descrise de Craig Larman în cartea Applying
UML and Patterns. An Introduction to Object
Oriented Analysis and Design
 Ne ajută să alocăm responsabilități claselor și
obiectelor în cel mai elegant mod posibil
 Exemple de principii folosite în GRASP:
Information Expert (sau Expert), Creator, High
Cohesion, Low Couplig, Controller
Polymorphism, Pure Fabrication, Indirection,
Protected Variations
35
 Să facă:
◦ Să facă ceva el însuși, precum crearea unui obiect
sau să facă un calcul
◦ Inițializarea unei acțiuni în alte obiecte
◦ Controlarea și coordonarea activităților altor obiecte

 Să cunoască:
◦ Atributele private
◦ Obiectele proprii
◦ Lucrurile pe care le poate face sau le poate apela

36
 Traducere: șablon, model

 Este o soluție generală la o problemă comună

 Fiecare pattern are un nume sugestiv și ușor de


reținut (ex. composite, observer, iterator,
singleton, etc.)

37
 Problemă: dat un anumit comportament
(operație), cărei clase trebuie să-i fie atribuit?

 O alocare bună a operațiilor conduce la sisteme


care sunt:
◦ Ușor de înțeles
◦ Mai ușor de extins
◦ Refolosibile
◦ Mai robuste

38
 Soluție:
 asignez o responsabilitate clasei care are
informațiile necesare pentru îndeplinirea acelei
responsabilități

 Recomandare:
 începeți asignarea responsabilităților evidențiind
clar care sunt responsabilitățile

39
 Carei clase trebuie sa-i fie asignată metoda
getTotal()? Mai trebuie alte metode?

40
41
Clasă Responsabilități
Sale să cunoască valoarea totală a cumpărăturilor
SalesLineItem să cunoască subtotalul pentru un produs
ProductSpecification să cunoască prețul produsului

42
43
 Problemă: cine trebie să fie responsabil cu
crearea unei instanțe a unei clase?
 Soluție: Asignați clasei B responsabilitatea de a
crea instanțe ale clasei A doar dacă cel puțin una
dintre următoarele afirmații este adevărată:
◦ B agregă obiecte de tip A
◦ B conține obiecte de tip A
◦ B folosește obiecte de tip A
◦ B are datele de inițializare care trebuie transmise la
instanțierea unui obiect de tip A (B este deci un Expert
în ceea ce privește crearea obiectelor de tip A)
 Factory pattern este o variantă mai complexă
44
 Cine este responsabil cu crearea unei instanțe
a clasei SalesLineItem?

45
 Deoarece Sale conține (agregă) instanțe de tip
SalesLineItem, Sale este un bun candidat pentru a i
se atribui responsabilitatea creării acestor instanțe

46
 Cuplajul este o măsură a gradului de
dependență a unei clase de alte clase
 Tipuri de Dependență:
◦ este conectată cu
◦ are cunoștințe despre
◦ se bazează pe
 O clasă care are cuplaj mic (redus) nu depinde
de “multe” alte clase; unde “multe” este
dependent de contex
 O clasă care are cuplaj mare depinde de multe
alte clase
47
 Probleme cauzate de cuplaj:
◦ schimbări în clasele relaționate forțează
schimbări locale

◦ clase greu de înțeles în izolare (scoase din


context)

◦ clase greu de refolosit deoarece folosirea lor


presupune și prezența claselor de care
depind

48
 Forme comune de cuplaj de la clasa A la
clasa B sunt:
◦ A are un atribut de tip B
◦ O instanță a clasei A apelează un serviciu
oferit de un obiect de tip B
◦ A are o metodă care referențiază B
(parametru, obiect local, obiect returnat)
◦ A este subclasă (direct sau indirect) a lui B
◦ B este o interfață, iar A implementează
această interfață
49
 Don’t talk to strangers

 Orice metodă a unui obiect trebuie să


apeleze doar metode aparținând
◦ lui însuși
◦ oricărui parametru al metodei
◦ oricărui obiect pe care l-a creat
◦ oricăror obiecte pe care le conține

50
 Diagrama de clase

 Diagrama de colaborare

51
 Exista legături între toate clasele
 Elimină cuplajul dintre Register și Payment

52
 Coeziunea este o măsură a cât de puternic sunt
focalizate responsabilitățile unei clase

 O clasă ale cărei responsabilități sunt foarte


strâns legate și care nu face foarte multe lucruri
are o coeziune mare

 O clasă care face multe lucruri care nu sunt


relaționate sau face prea multe lucruri are o
coeziune mică (slabă)

53
 Probleme cauzate de o slabă coeziune:
◦ greu de înțeles

◦ greu de refolosit

◦ greu de menținut

◦ delicate; astfel de clase sunt mereu supuse la


schimbări

54
 Sunt principii vechi în design-ul software

 Promovează un design modular

 Modularitatea este proprietatea unui sistem care


a fost descompus într-o mulțime de module
coezive și slab cuplate

55
 Problemă: Cine este responsabil cu tratarea unui
eveniment generat de un actor?

 Aceste evenimente sunt asociate cu operații ale


sistemului

 Un Controller este un obiect care nu ține de


interfața grafică și care este responsabil cu
recepționarea sau gestionarea unui eveniment

 Un Controller definește o metodă


corespunzătoare operației sistemului
56
 Soluție: asignează responsabilitatea pentru
recepționarea sau gestionarea unui eveniment
unei clase care reprezintă una dintre
următoarele alegeri:
◦ Reprezintă întregul sistem sau subsistem (fațadă
controller)
◦ Reprezintă un scenariu de utilizare în care apare
evenimentul;

57
 În mod normal, un controller ar trebui să delege
altor obiecte munca care trebuie făcută;
 Controller-ul coordonează sau controlează
activitatea, însă nu face prea multe lucruri el
însuși
 O greșeală comună în design-ul unui controller
este să i se atribuie prea multe responsabilități
(fațade controller)

58
 Forward & Reverse Engineering

 GRASP
◦ Information Expert
◦ Creator
◦ Low coupling
◦ High cohesion
◦ Controller

59
 1) E etic ca o firmă (mare) să facă RE pe un
produs de la concurență?

 2) De ce nu trebuie încurajat RE? Care sunt


efectele RE?

 3) Cum putem folosi informațiile legate de


coeziune și cuplaj? Când evaluăm un proiect.
Când evaluăm un membru al echipei.

60
 Reverse Engineering and Design Discovery: A
Taxonomy, Chikofsky, E.J. and Cross, J.,
January, 1990

 Craig Larman. Applying UML and Patterns. An


Introduction to Object Oriented Analysis and
Design

 Ovidiu Gheorghieș, Curs 6 IP

61
 DJ Java Decompiler 3.10.10.93:
http://www.softpedia.com/progDownload/DJ-Java-Decompiler-
Download-13481.html
 Open Office: http://ro.wikipedia.org/wiki/OpenOffice.org
 UML Reverse Engineering for Existing Java, C# , and Visual Basic .NET Code:
http://www.altova.com/umodel/uml-reverse-engineering.html
 Reverse Engineering:
http://en.wikipedia.org/wiki/Reverse_engineering
 PROTO 3000 3D Engineering Solutions:
http://www.proto3000.com/services.aspx
 HAR2009: http://www.degate.org/HAR2009/
 Degate: http://www.degate.org/screenshots/
 Inteligent: http://www.intelligentrd.com/
 Smartphones RE: http://www.cytraxsolutions.com/2011/
01/smartphones-security-and-reverse.html

62
 WebProjectManager: http://profs.info.uaic.ro/~adrianaa/uml/
 Diagrame de Stare și de Activitate:
http://software.ucv.ro/~soimu_anca/itpm/Diagrame%20de%20
Stare%20si%20Activitate.doc
 Deployment Diagram:
http://en.wikipedia.org/wiki/Deployment_diagram
http://www.agilemodeling.com/artifacts/deploymentDiagram.
htm
 GRASP:
http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)
 http://web.cs.wpi.edu/~gpollice/cs4233-
a05/CourseNotes/maps/class4/GRASPpatterns.html
 Introduction to GRASP Patterns:
http://faculty.inverhills.edu/dlevitt/CS%202000%20(FP)/GRASP
%20Patterns.pdf 63

You might also like