1. February 8, 2006copyright Thomas Pole 2003-2005, all rights reserved 1 Lecture 3: Reusable Software Packaging: Source Code and Text Chapter 2: Dealing with Complexity

2. February 8, 2006copyright Thomas Pole 2003-2005, all rights reserved 2 Agenda Catching up: from last week –Reusable software source code mechanisms for capturing commonality and variability. Tailoring and Specialization Examples Mixins Generic Programming Reusable Software Packaging: Source Code Text review: “Software Factories” Chapter 2, Dealing with Complexity –We’ll be pushing back the schedule one week on the reading to let people catch up. Q&A

3. February 8, 2006copyright Thomas Pole 2003-2005, all rights reserved 3 Commonality and Variability (C&V) Coding Mechanisms C&V Mechanism 1: Tailoring –Example: TextArrays C&V Coding Mechanism 2: Specialization –Example: TextClasses Mixins –Object Oriented Multiple Inheritance Generic Programming –Examples: Abstract Data Types (Ada) and Templates (C++ and C#)

4. February 8, 2006copyright Thomas Pole 2003-2005, all rights reserved 4 Example: TextArrays Mechanism: Tailoring Commonality: –Not well controlled with tailoring –Text string types, manage values and length Variability: –Values, lengths, anything else you want to change

5. February 8, 2006copyright Thomas Pole 2003-2005, all rights reserved 5 Example: TextClasses Mechanism: Specialization Commonality: –More control then tailoring –The specifications of the methods, more could be controlled using this mechanism. –Whatever is inherited Variability: –Like tailoring, still not strongly controlled –Pre-planned collections of classes, more control –Whatever is defined, or redefined in the derived classes

6. February 8, 2006copyright Thomas Pole 2003-2005, all rights reserved 6 C&V Coding Mechanism 3: Mixins (Multiple Inheritance) Allows the one from column a and one from column b approach. Requires not a reusable class, but a set of reusable classes that can be grouped into categories. Thing of a group of user interface components (drop down lists, menus, combo-boxes) and a group of data structures (sets, lists) –Pick one from interface components and one from data structures to defined new types. Example: TextMixins

7. February 8, 2006copyright Thomas Pole 2003-2005, all rights reserved 7 Example: TextMixins Mechanism: Mixins, multiple inheritance Commonality –In commonality and variability, an example of a pre- planned set of classes –Creates types of character strings that hold strings of fixed length and/or specific values. Variability –Define the length and/or the valid values. –Define a set length or range of length –Define a set of values or alphabetical range of values

8. February 8, 2006copyright Thomas Pole 2003-2005, all rights reserved 8 C&V Coding Mechanism 4: Generic Programming Parameterize a type, the way you parameterize a function. C++ templates C# templates Ada Abstract Data types Example: –TextTemplates and TextTemplates2

9. February 8, 2006copyright Thomas Pole 2003-2005, all rights reserved 9 Example: TextTemplates Mechanism: Generic Programming Commonality: –Text strings, of specific range of lengths, and (with TextArrayN2) specific values. –Generic programming is an effective mechanism for controlling commonality an variability, but still allowing future evolution. Variability: –Range of size and range of values can be set.

10. February 8, 2006copyright Thomas Pole 2003-2005, all rights reserved 10 Reusable Software Packaging: Source Code Packaging Software –Purpose: What is the problem to solve? Software Development Assets –MetaData: What is in a reusable software package besides the software source code. –Meta Data captures more then Commonality and Variability

11. February 8, 2006copyright Thomas Pole 2003-2005, all rights reserved 11 Packaging Software, Why? We’ve already covered part of packaging: classes, templates, functions, etc. Reusing source code requires more then just the source code, it’s also meta-data describing the software –How to use it: integration, invocation, etc. –Constraints on using it, what it can’t do, or shouldn’t be used to do (undetermined behavior). –Programming Language related: Language version, compiler version, platform version. –Licensing, copyright, etc. To reuse software the source code and the meta data need to be packaged together.

12. February 8, 2006copyright Thomas Pole 2003-2005, all rights reserved 12 Reusable Source Code: A Complete Package Physical Package of the Source Code Additional Information –Purpose of the reusable software code, what does it accomplish, what requirements and/or design features does it implement. –How to use it, what to not use it for, constriants on using it. –Legal and copyright details, license terms, etc.

13. February 8, 2006copyright Thomas Pole 2003-2005, all rights reserved 13 Source Code Physical Packaging The reusable software code packaged as: –Static (unchanging) packages Modules, e.g. functions, function libraries Types, e.g. classes, or class libraries –Dynamic (parameterizable) packages mixins collections Generic programming, e.g. C++ templates

14. February 8, 2006copyright Thomas Pole 2003-2005, all rights reserved 14 Source Code Additional Information (Meta Data) Internal comments, in the code. Electronic, hard copy, and/or hyperlinked documentation. Test harness, useful to show that the software does what it should, as well as demonstrating how to integrate it into an application.

15. February 8, 2006copyright Thomas Pole 2003-2005, all rights reserved 15 Class Exercise #1 Due next week, please submit by email to prof@hisdomain.net prof@hisdomain.net Identify a reusable source package by: –Purpose: what does it accomplish –Describe it’s: Commonality and Variability Physical packaging, choose a form and desribe how that form (e.g. mixin class library) captures the commonality and variability.

16. February 8, 2006copyright Thomas Pole 2003-2005, all rights reserved 16 Break 15 minutes Next: Software Factories, Ch 2: Dealing with Complexity

17. February 8, 2006copyright Thomas Pole 2003-2005, all rights reserved 17 “Software Factories” Ch 2: Dealing with Complexity We’ll continue with Ch 2 this week, leaving Ch 3 Dealing with Change for next week –We’ll push back the reading schedule a week to let everyone catch up with the reading. –We will catch up by session 11 –There is an updated syllabus on the web site.

18. February 8, 2006copyright Thomas Pole 2003-2005, all rights reserved 18 Points of Interest in Chapter 3: Dealing with Complexity (1 of N) One of the two fundamental forces, along with change. Advances in technology are offset by increased demand for more complex systems. Two types: essential and accidental –Essential: inherent, a product of the number of features and the number of relationships among those features. –Accidental: complexity introduced, or added to the essential complexity by the solution: therefore can be reduced by changing the way we solve the problem.

19. February 8, 2006copyright Thomas Pole 2003-2005, all rights reserved 19 Dealing with Complexity (2 of n) Accidental Complexity –Caused (in part) when fine grained, general purpose abstractions (e.g. integers and strings) are used to implement coarse grained, problem-specific concepts (e.g. customers and products). Problem specific is also called (application) domain specific, domains or markets of applciations –Application Domain Examples: accounting software, customer relationship management software. There are also engineering domains, defined by how software is built. –Engineering Domains Examples: Web Development, Distributed Systems, Numeric Computation, Mathematical Modelling

20. February 8, 2006copyright Thomas Pole 2003-2005, all rights reserved 20 Dealing with Complexity (3 of n) Feature Delocalization: logically related functionality and state (objects) in the problem space (the specification of the problem the software solves) are distributed across multiple objects in the solution space (the specification of the solution application, the design and/or implementation.) Traceability Problem Reconstruction Problem Refinement in Software Development

21. February 8, 2006copyright Thomas Pole 2003-2005, all rights reserved 21 Dealing with Complexity (4 of n) Supportability: Cohesion, Encapsulation, Loose Coupling (and Tight Cohesion), Portability, Interoperability, Level of Factoring. Abstraction: removing details. –Raising the level of, applying, developing abstractions. Top Down, Bottom Up Reusing Knowledge Granularity and Specificity Narrowing the abstraction gap Packaging Abstractions: Platform Based, Language Based, Relative Levels of abstractions

22. February 8, 2006copyright Thomas Pole 2003-2005, all rights reserved 22 Dealing with Complexity (5 of 5) Current Methods and Practices –Encapsulation –Partitioning Responsibility –Documenting Design –Automating Development –Organizing Development

23. February 8, 2006copyright Thomas Pole 2003-2005, all rights reserved 23 Questions? Read the introduction through chapter 3 for next week. Exercise #1 assigned, due next week.