1. Software Design Mihaela Dinsoreanu, PhD Contact: room D01, Baritiu 26-28 E-mail: mihaela.dinsoreanu@cs.utcluj.ro Spring 2011 Computer Science Department, TUC-N

2. H OUSEKEEPING D ETAILS Time & Location: See Schedule on www.ac.utcluj.rowww.ac.utcluj.ro Prerequisites: Software Engineering Course Programming Techniques Course Grading: Project 25% Lab 25% Final Exam 50% Spring 2011 Computer Science Department, TUC-N

3. H OUSEKEEPING CONTINUED.. TA’s prep. ing. Ionut Anghel - 30231, 30232 prep.ing. Pop Cristina - 30234, 30235 ing. Sorin Suciu - 30431 ing. Grigore Vlad - 30236 ing. Iulia Vartic- 30433, 30434, 30234 ing. Tudor Vlad - 30432 Communication ONLY via your utcluj account! Spring 2011 Computer Science Department, TUC-N

4. H OUSEKEEPING CONTINUED.. Lab sessions are compulsory no more than 3 absences allowed! 2 types of projects Common Research-oriented (can be continued as DS projects and Diploma projects) Adaptive systems (contextual advertising) Semantic Business Intelligence Data mining Course files http://users.utcluj.ro/~dinso/PS2011 …to be set up Spring 2011 Computer Science Department, TUC-N

5. R EFERENCES OOD Design Principles www.objectmentor.com OO Development Methodologies G. Booch, J. Rumbaugh, and I. Jacobson. The Unified Modeling Language User Guide. Addison-Wesley, 1998. R.S. Pressman, Software Engineering – A Practitioner’s Approach, McGraw- Hill, 5th edition, 2001, ISBN 0073655783. RUP: Best Practices for Software Development Teams, Rational whitepaper, http://www-128.ibm.com/developerworks/rational/library/253.html Design Patterns E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns. AddisonWesley, 1995. Craig Larman, Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd Edition), Prentice Hall, 2004, ISBN: 0131489062 Software Architectures Buschmann, Frank, Regine Meunier, Hans Rohnert, Peter Sornmerlad, and Michael Stal. 2001. Pattern-oriented system architecture, volume 1: A system of patterns. Hoboken, NJ: John Wiley & Sons. Fowler Martin, Patterns of Enterprise Application Architecture, Addison-Wesley Professional, 2002 Courses B. Meyer (ETH Zurich) G. Kaiser (Columbia Univ. NY) I. Crnkovic (Sweden) R. Marinescu (Univ. Timisoara) Spring 2011 Computer Science Department, TUC-N

6. PRETEST (10 MIN ) 1. What software development methodologies do you know? 2. What types of diagrams would you use to represent dynamic behavior? 3. What types of diagrams would you use to represent a domain model? 4. How do we model requirements ? 5. What is the outcome of software design? Spring 2011 Computer Science Department, TUC-N

7. O BJECTIVES After completing this course, the student should be able to: Describe Object Oriented Analysis and Design Concepts Analyze system requirements and identify use cases Expand use cases into analysis and design models Produce detailed static object models and dynamic behavioral models Apply design patterns to refine analysis and design models Apply class design principles to develop object models Construct testable and adaptable designs Adapt and implement a design model in an OO language (i.e. Java, C#, C++) Spring 2011 Computer Science Department, TUC-N

8. C ONTENT Software Quality Assurance Software Quality attributes. Introduction to software architecture concepts like: Architectural Patterns and Styles Design Patterns Most important OOD principles Class Design Principles, Principles of Package Coupling and Cohesion GRASP OO Design metrics Spring 2011 Computer Science Department, TUC-N

9. T ODAY ’ S OUTLINE Software quality dimensions Product Process Software design techniques Concepts Principles Spring 2011 Computer Science Department, TUC-N

10. S OFTWARE ENGINEERING The collection of processes, methods, techniques, tools and languages for developing quality operational software. [B. Meyer] Spring 2011 Computer Science Department, TUC-N

11. S OFTWARE QUALITY External factors: visible to customers (not just end users but e.g. purchasers) Examples : ease of use, extendibility, timeliness Internal factors: perceptible only to developers Examples : good programming style, information hiding Only external factors count in the end, but the internal factors make it possible to obtain them. Spring 2011 Computer Science Department, TUC-N

12. S OFTWARE QUALITY : PROCESS / PRODUCT Product: properties of the resulting software For example: correctness, efficiency Process: properties of the procedures used to produce and maintain the software Glossary follows Spring 2011 Computer Science Department, TUC-N

13. E XTERNAL QUALITY FACTORS Product immediate: Correctness Robustness Security Ease of use Ease of learning Efficiency Spring 2011 Computer Science Department, TUC-N

14. E XTERNAL QUALITY FACTORS ( CONT ’ D ) Product long-term: Extendibility Reusability Portability Process Timeliness Cost Effectiveness Spring 2011 Computer Science Department, TUC-N

15. R ELIABILITY Correctness The systems’ ability to perform according to the specifications, in cases covered by the specification Robustness The systems’ ability to perform reasonably in cases not covered by the specification Security The systems’ ability to protect itself against malicious use Spring 2011 Computer Science Department, TUC-N

16. M ODULARITY Reusability + Extendibility Architectural techniques must ensure decentralization of modules Some Principles Composability Decomposability Continuity Information hiding Open-closed principle Single choice principle … Spring 2011 Computer Science Department, TUC-N

17. S OFTWARE D ESIGN T ECHNIQUES What are Software Design Techniques? SD Techniques provide a set of practices for analysing, decomposing, and modularising software system architectures In general, SD Techniques are characterized by structuring the system architecture on the basis of its objects (and classes of objects) rather than the actions it performs. Spring 2011 Computer Science Department, TUC-N

18. L EARNING SD T ECHNIQUES Junior Developer ->Rules algorithms, data structures and software languages write programs, although not always good ones Senior Developer ->Principles software design & programming paradigms with pros and cons importance of cohesion, coupling, information hiding, dependency management Master ->Patterns study the "design of masters" Understand! Memorize! Apply! Spring 2011 Computer Science Department, TUC-N

19. W HERE DO YOU STAND ? You know the Rules 1-2 OO programming languages (Java, C++, C#) some experience in writing programs (< 10 KLOC) You heard about Principles "Open-Closed"; "Liskov Substitution Principle" etc. Maybe (in)voluntary applied some of them You aim to become "design masters" but... you believe that writing good software is somehow "magic" exclusively tailored for geniuses, gurus Spring 2011 Computer Science Department, TUC-N

20. R OADMAP Define good Design Goals of Design Concepts and Principles of Design Metrics for Design Apply good Design Patterns Analysis Architectural Design Spring 2011 Computer Science Department, TUC-N

21. G OALS OF D ESIGN Decompose system into components i.e. identify the software architecture Describe component functionality informally or formally Determine relationships between components identify component dependencies determine inter-component communication mechanisms Specify component interfaces Interfaces should be well defined facilitates component testing and team communication Spring 2011 Computer Science Department, TUC-N

22. C ONCEPTS AND PRINCIPLES Concepts Modularity Composition/Decomposition Principles Software quality Systematic reuse Spring 2011 Computer Science Department, TUC-N

23. M ODULARITY A modular system is one that's structured into identifiable abstractions called components Components should possess well-specified abstract interfaces Components should have high cohesion and low coupling A software construction method is modular if it helps designers produce software systems made of autonomous elements connected by a coherent, simple structure. [B. Meyer] Spring 2011 Computer Science Department, TUC-N

24. B ENEFITS Modularity facilitates software quality factors, e.g.: Extensibility well-defined, abstract interfaces Reusability low-coupling, high-cohesion Portability hide machine dependencies Modularity is important for good design since it Enhances for separation of concerns Enables developers to reduce overall system complexity via decentralized software architectures Increases scalability by supporting independent and concurrent development by multiple personnel Spring 2011 Computer Science Department, TUC-N

25. M ETRICS FOR G OOD M ODULAR D ESIGN Meyer’s Criteria Decomposability Are larger components decomposed into smaller components? Composability Are larger components composed from smaller components? Understandability Are components separately understandable? Continuity Do small changes to the specification affect a localized and limited number of components? Protection Are the effects of run-time abnormalities limited to a small number of related components? Spring 2011 Computer Science Department, TUC-N

26. D ECOMPOSABILITY Decompose problem into smaller sub-problems that can be solved separately Goal : Division of Labor keep dependencies explicit and minimal Example : Top-Down Design Counter-example : Initialisation Module initialize everything for everybody Spring 2011 Computer Science Department, TUC-N

27. C OMPOSABILITY Freely combine modules to produce new systems Reusability in different environments  components Example : Math libraries; UNIX command & pipes Counter-example : use of pre- processors Spring 2011 Computer Science Department, TUC-N

28. U NDERSTANDABILITY Individual modules understandable by human reader Counter-example : Sequential Dependencies (A | B | C) contextual significance of modules Spring 2011 Computer Science Department, TUC-N

29. C ONTINUITY Small change in specifications results in: Small changes in the architecture (affects only a few modules, not the overall architecture) Example : Principle of Uniform Access Counter-Example : data-driven design Spring 2011 Computer Science Department, TUC-N

30. P ROTECTION Effects of an abnormal run-time condition is limited to a few modules Example : Validating input at source Counter-example : Undisciplined exceptions Spring 2011 Computer Science Department, TUC-N

31. M EYER ' S P RINCIPLES OF M ODULARITY Decomposition Composition Direct Mapping Few Interfaces Small Interfaces Explicit Interfaces Uniform Access Information Hiding Spring 2011 Computer Science Department, TUC-N

32. D ECOMPOSITION – D IVIDE AND C ONQUER 1. Select a piece of the problem initially, the whole problem 2. Determine the components in this piece using a design paradigm e.g. functional, structured, object-oriented, generic, etc. 3. Describe the components interactions 4. Repeat steps 1 through 3 until some termination criteria is met e.g., customer is satisfied, run out of money, etc. Spring 2011 Computer Science Department, TUC-N

33. C OMPONENT... a SW entity encapsulating the representation of an abstraction... a vehicle for hiding at least one design decision... a "work" assignment for a programmer or group of programmers... a unit of code that has one (or more) name(s) has identifiable boundaries can be (re-)used by other components encapsulates data hides unnecessary details can be separately compiled Spring 2011 Computer Science Department, TUC-N

34. C OMPONENT I NTERFACE A component interface consists of several sections: Exports services provided to other components Imports services required from other components Access Control e.g. protected/private/public Spring 2011 Computer Science Department, TUC-N

35. D ECOMPOSITION P RINCIPLES P1. Don't design components to correspond to execution steps Since design decisions usually transcend execution time [Parnas72] P2. Decompose so as to limit the effects of design decisions Anything that spreads within the system will be expensive to change P3. Components should be specified by all information needed to use the component and nothing more! Spring 2011 Computer Science Department, TUC-N

36. D IRECT M APPING Keep the structure of the solution compatible with the structure of the modeled problem domain clear mapping (correspondence) between the two Impact on: Continuity easier to assess and limit the impact of change Decomposability decomposition in the problem domain model as a good starting point for the decomposition of the software Spring 2011 Computer Science Department, TUC-N

37. F EW INTERFACES Don’t talk to many! Every module should communicate with as few others as possible rather n-1 than n(n-1)/ 2 affects... Continuity, Protection, Understandability, Composability Spring 2011 Computer Science Department, TUC-N

38. S MALL INTERFACES Don’t talk a lot! If two modules communicate, they should exchange as little information as possible limited "bandwidth" of communication Affects Continuity and Protection Spring 2011 Computer Science Department, TUC-N

39. E XPLICIT INTERFACES Talk loud and clear! Whenever two modules A and B communicate, this must be obvious from the specification of A or B or both. Affects: Decomposability and Composability, Continuity, Understandability Spring 2011 Computer Science Department, TUC-N

40. U NIFORM A CCESS Functionalities managed by a module should be accessible to its clients independent on their implementation method. Affects: Decomposability, Continuity. Example Spring 2011 Computer Science Department, TUC-N

41. I NFORMATION H IDING Motivation: design decisions that are subject to change should be hidden behind abstract interfaces, i.e. components Components should communicate only through well- defined interfaces Each component is specified by as little information as possible Continuity: If internal details change, client components should be minimally affected not even recompiling or linking Decomposability Spring 2011 Computer Science Department, TUC-N

42. Q UESTIONS ? Thank you! Spring 2011 Computer Science Department, TUC-N