Recapitulare IP – 4 Octombrie 2010 Adrian Iftene [email protected]
Recapitulare – noțiuni pe care ne vom baza
◦ Definiție
◦ Modele de dezvoltare
◦ Etapele dezvoltării proiectelor
Ingineria cerințelor
Diagrame UML
Design patterns (GRASP, GOF)
Quality assurance
Întreținere
◦ Calitatea programelor
◦ Copyright
Ingineria programării (Software engineering)
Modele de proiectare (Design models)
Ingineria cerinţelor (Requirements identification)
Diagrame UML (UML diagrams)
Design patterns
Testare şi debug (Testing and debugging)
Întreţinere (Maintenance)
Metrici software (Software metrics)
Managementul proiectelor (Project management)
Drepturi de autor (Author rights)
Cuvinte cheie din definiție:
◦ Dezvoltarea de aplicații mari
◦ Principii inginerești
◦ Programe sigure și eficiente
◦ Funcționare, întreținere, retragere
◦ Software engineer
◦ Gestionare proiect: coordonare echipe, comunicare, planificare, buget
Cum
efectuăm activitaţile indicate de etapele dezvoltării programelor Exemple de modele de dezvoltare:
◦ Ad-hoc: descurcă-te cum poţi
◦ Modelul în cascadă (cu feedback)
◦ Prototipizare
◦ Modelul în spirală
◦ RUP (Rational Unified Process) (Inception, Elaboration, Construction, Transition)
◦ XP (Extreme Programming)
◦ Agile
◦ Lean
◦ Scrum
Este o disciplină inginerească care se ocupă de toate aspectele dezvoltării unui program
Propune adoptarea unei abordari sistematice şi organizate a procesului de dezvoltare
software
Propune folosirea tehnicilor şi instrumentelor adecvate având în vedere
◦ problema care trebuie rezolvată
◦ restricţiile impuse
◦ resursele disponibile
Analiza cerinţelor (Requirements analisys)
Proiectarea architecturală (Arhitectural design)
Proiectarea detaliata (Detailed design)
Scrierea codului (Implementation)
Integrarea componentelor (Integration)
Validare (Validation)
Verificare (Verification)
Întreţinere (Maintenance)
Se stabileşte
ce anume vrea clientul ca programul să facă
Scopul este înregistrarea cerinţelor într-o manieră cât mai clară şi mai fidelă
Probleme
◦ Comunicare
◦ Negociere
◦ Sfătuirea clientului
Cine? Project Manager, Program Manager sau Business Analyst
De ce?
Arhitecturală
◦ Programul este împarţit în module sau componente mai simple, care pot fi abordate individual
Detaliată
◦ Se proiecteaza fiecare modul al aplicaţiei, în cele mai mici detalii
Diagrame UML
◦ UseCase, clase, interacțiuni, secvență, colaborare, stări, activități, pachete
Reverse & Forward Engineering
Activități…
stări…
Secvență…
Implementare
◦ Proiectul detaliat este transpus într-un limbaj de programare
◦ Acesta se realizează modular, pe structura rezultată la proiectarea arhitecturală folosind design patterns
Integrare
◦ Modelul big-bang
◦ Modelul incremental
“Design patterns capture solutions that have
developed and evolved over time” (GOF -
Gang- Of-Four
(because of the four authors who wrote it),Design Patterns: Elements of Reusable
Object-Oriented Software)
In software engineering (or computer science), a design pattern is a general repeatable solution to a commonly occurring problem in software design
The design patterns are language-independent strategies for solving common object-oriented
Elements:
1. Pattern name
2. Problem (when, context, list of conditions)
3. Solution (elements, relationships, responsibilities) 4. Consequences (results, understanding, evaluation) 5. Intent, also known as, motivation, applicability,
structure, participants, implementation, known uses
GRASP
GOF
◦ Creational patterns
◦ Structural patterns
◦ Behavioral patterns
Fundamental, Partitioning, GUI, Organizational Coding, Optimization Coding, Robustness
Coding, Testing, Transactions, Distributed
Architecture, Distributed Computing, Temporal, Database, Concurrency patterns
GRASP - General Responsibility Assignement Software Patterns (Principles)
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
Problemă: dat un anumit comportament
(operaţie), cărei clase trebuie să-i fie atribuit?
Soluţie: asignez o responsabilitate clasei care are informaţiile necesare pentru îndeplinirea acelei responsabilităţi
O alocare bună a operaţiilor conduce la sisteme care sunt:
◦ Uşor de înţeles, Mai uşor de extins, Refolosibile, Mai robuste
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
Probleme cauzate de cuplaj: greu de modificat, greu de înțeles în izolare, greu de refolosit
Vizualizare: diagrame de clase și diagrame de colaborare
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
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
Abstract Factory groups object factories that have a common theme (PC-Server-Workstation)
Builder constructs complex objects by separating construction and representation (fast food menu)
Factory Method creates objects without specifying the exact class to create (Hello <>, Open/New
options)
Prototype creates objects by cloning an existing object (editor for music scores, Cloneable/clone)
Singleton restricts object creation for a class to only one instance (Logger system)
Not in GOF book: Lazy initialization, Object pool, Multiton, Resource acquisition is initialization
Adapter allows classes with incompatible interfaces to work together (Wrapper, Plug-socket)
Bridge decouples an abstraction from its implementation (Shapes-OS)
Composite composes zero-or-more similar objects (compositions, container, pictures, employees)
Decorator dynamically adds/overrides behavior (Christmas tree)
Facade provides a simplified interface (compiler, glass-building, JDBC, store keeper)
Flyweight use sharing to reduce the cost (MS Word - characters formatting)
Proxy provides a placeholder (surrogate) (MS Word –
Chain of responsibility delegates commands to a chain (contextual Help, multi level filter)
Command creates objects which encapsulate actions and parameters (restaurant waiter)
Interpreter implements a specialized language
Iterator accesses the elements sequentially
Mediator allows loose coupling between classes (control tower)
Memento provides the ability to restore an object to its previous state
Observer allows to observer objects to see an event (Excel graphs)
State allows an object to alter its behavior when its internal state changes (TCPConnection)
Strategy allows one of a family of algorithms to be selected on-the-fly at runtime (+-* context)
Template defines an algorithm as an abstract class, allowing its subclasses to provide
concrete behavior (Game: initialize, makePlay,…)
Visitor separates an algorithm from an object structure
With more than 20 design patterns to choose from, it might be hard to find the one that
addresses a particular design problem
Approaches to finding the design pattern that's right for your problem:
1. Consider how design patterns solve design problems 2. Scan Intent sections
3. Study relationships between patterns
4. Study patterns of like purpose (comparison) 5. Examine a cause of redesign
6. Consider what should be variable in your design
1. Read the pattern once through for an overview
2. Go back and study the Structure, Participants, and Collaborations sections
3. Look at the Sample Code section to see a concrete example
4. Choose names for pattern participants that are meaningful in the application context
5. Define the classes
6. Define application-specific names for operations in the pattern
7. Implement the operations to carry out the
responsibilities and collaborations in the pattern
Validare: ne asigurăm că programul îndeplineşte cerinţele utilizatorului
◦ Construim produsul corect?
Verificare: ne asigurăm că programul este stabil şi că funcţionează corect din punctul de vedere al dezvoltatorilor.
◦ Construim corect produsul?
Unit testing
Refers to planned and systematic production
processes that provide confidence in a product's suitability for its intended purpose.
A set of activities intended to ensure that products satisfy customer requirements
QA cannot absolutely guarantee the production of quality products, unfortunately, but makes this more likely
Two key principles characterize QA:
◦ "fit for purpose" - the product should be suitable for the intended purpose, and
Price Time
Quality
ISO 9000 is a family of standards for quality management systems
Some of the requirements in ISO 9001 (from ISO 9000 family) include
◦ a set of procedures;
◦ monitoring processes;
◦ keeping adequate records;
◦ checking output for defects;
◦ regularly reviewing individual processes;
◦ facilitating continual improvement
When?
Aims?
Problems: communication, incomplete requirements, design
Bug: Effects, Prevention, Life cycle
Professional testing?
Unit, Acceptance, Regression
Manual & Automation testing
Usability, security
Internationalization & localization
După livrare
◦ Sunt descoperite greșeli ce trebuie reparate
◦ Pot apărea schimbări în specificații
◦ Pot apărea noi cerințe
◦ Instruirea celor ce vor folosi produsul
Întreținere = gestionarea acestor tipuri de probleme
Concepte
◦ Siguranţă
◦ Eficienţă
◦ Întreţinere
◦ Uzabilitate
Metrici de bază
◦ KLOC: Kilo Lines Of Code (mii linii de cod)
◦ Effort, PM: Person – Month (Om – lună)
Copyright
Pagina cursului de IP Adrian Iftene (2009 și 2010) http://thor.info.uaic.ro/~adiftene/Scoala/2009/IP/
Pagina lui Ovidiu Gheorghieş (a lucrat cu Adriana G.) http://thor.info.uaic.ro/~ogh/ip/
Ian Sommerville: Software Engineering, Addison Wesley, 2001
Craig Larman: Applying UML and Patterns, Addisson Wesley, 2002
Erich Gamma, Richard Helm, Ralph Johnson, John Vissides: Design Patterns, Elements of Reusable Object-Oriented Software, Addisson Wesley, 1998
Internet
