1. Requirements Analysis 16. 1 Analysis Patterns - 2005b516.ppt © Copyright De Montfort University 2000 All Rights Reserved INFO2005 Requirements Analysis Analysis Patterns Department of Information Systems

2. Requirements Analysis 16. 2 Analysis Patterns - 2005b516.ppt © Copyright De Montfort University 2000 All Rights Reserved Learning Objectives v Understand the concept of patterns v Illustrate with an example from architecture v Understand how patterns can apply to many aspects of software development v Produce a simple analysis pattern v Examine some complex analysis patterns

3. Requirements Analysis 16. 3 Analysis Patterns - 2005b516.ppt © Copyright De Montfort University 2000 All Rights Reserved Why Patterns? v Nobody solves every problem from scratch v Good solutions are used again and again v E.g. a generalised, abstract class structure may meet many application needs v If we document solutions in a standard format, this saves having to rediscover them next time v We can apply them immediately to new problems v Patterns help us to reuse good practice

4. Requirements Analysis 16. 4 Analysis Patterns - 2005b516.ppt © Copyright De Montfort University 2000 All Rights Reserved Patterns... v... Are problem-centred, not solution- centred v … Are Discovered, not invented - they already exist v...Complement existing techniques, do not replace them v...Capture and communicate “best practice” and expertise

5. Requirements Analysis 16. 5 Analysis Patterns - 2005b516.ppt © Copyright De Montfort University 2000 All Rights Reserved Patterns... v …Originally used in building architecture v …Applied to software design for c. 6 years v …Now used to convey good practice in: –System design –Requirements analysis –Organisation structures –Project management –General modelling approaches –...

6. Requirements Analysis 16. 6 Analysis Patterns - 2005b516.ppt © Copyright De Montfort University 2000 All Rights Reserved Origin of Patterns v Christopher Alexander is credited with the “invention” of patterns v His book “A Pattern Language” is a catalogue of 253 patterns v These document how to construct rooms, buildings and whole communities that people would like to live and work in

7. Requirements Analysis 16. 7 Analysis Patterns - 2005b516.ppt © Copyright De Montfort University 2000 All Rights Reserved 8 What is a Pattern? “Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of a solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice” (Alexander, 1977)

8. Requirements Analysis 16. 8 Analysis Patterns - 2005b516.ppt © Copyright De Montfort University 2000 All Rights Reserved Example: Alexander Pattern 196 Pattern Name: Corner Doors Problem: The success of a room depends…on the position of the doors. If the doors create a pattern of movement which destroys the places in a room, the room will never allow people to be comfortable. Forces: Several drawings of rooms with doors in different positions are shown. Traffic flows with corner doors are shown and he discusses how traffic flow divides the room into spaces. Constraints: He notes the issues and constraints of small vs. very large rooms. Solution: In small rooms put doors in corners. Related Patterns: Low Doorway (224), Closets between rooms (198).

9. Requirements Analysis 16. 9 Analysis Patterns - 2005b516.ppt © Copyright De Montfort University 2000 All Rights Reserved Minimum Elements of a Pattern Pattern Name: Should be easy to remember Reflects the pattern’s content. May include ‘aliases’ or ‘AKA’. Problem: Statement of the problem that can be written in question form. Context: Describes the context of the problem. Any ‘pre-conditions’ should also be noted here. Forces: What causes the problem to come about? What is required to solve the problem? Solution: A direct and precise statement.

10. Requirements Analysis 16. 10 Analysis Patterns - 2005b516.ppt © Copyright De Montfort University 2000 All Rights Reserved Analysis Patterns: Definition v “A pattern is an idea that... –has been useful in one practical context... –and will probably be useful in others” v “Analysis patterns… –are groups of concepts… –that represent a common construction in business modelling... –may be relevant to only one domain, or may span many domains” (Fowler, 1997)

11. Requirements Analysis 16. 11 Analysis Patterns - 2005b516.ppt © Copyright De Montfort University 2000 All Rights Reserved Fowler’s Modelling Principles v Fowlers principles guide the use and development of patterns: –Models are not right or wrong… –…they are more or less useful –Patterns are a starting point, not a destination

12. Requirements Analysis 16. 12 Analysis Patterns - 2005b516.ppt © Copyright De Montfort University 2000 All Rights Reserved Simple Analysis Pattern v Consider: –A phone bill –A credit card statement –A mail order dispatch note –A supermarket till receipt –A bank statement v Most examples of these have some common characteristics...

13. Requirements Analysis 16. 13 Analysis Patterns - 2005b516.ppt © Copyright De Montfort University 2000 All Rights Reserved VISA Statement Example VISAStatement accountNumber statementDate customerName dueDate calcStatementTotal calcAvailableCredit calcMinimumPayment StatementLine 1 1..* transactionDate itemDetails itemAmount v Based on a Co-op Bank VISA statement

14. Requirements Analysis 16. 14 Analysis Patterns - 2005b516.ppt © Copyright De Montfort University 2000 All Rights Reserved Bank Account Statement Example AccountStatement branchNumber accountNumber customerName statementDate calcTotalWithdrawn calcTotalPaidIn calcBalanceCF StatementLine 1 1..* transactionDate itemDetails itemAmount calcCurrentBalance v Based on a RBS current account statement

15. Requirements Analysis 16. 15 Analysis Patterns - 2005b516.ppt © Copyright De Montfort University 2000 All Rights Reserved Mail Order Invoice Example Invoice invoiceNumber accountNumber customerName invoiceDate calcGoodsValue calcDeliveryCharge calcVAT calcAmountDue InvoiceLine 1 1..* catalogueCode quantityDespatch ed itemDescription unitPrice VATCode calcLineTotal v Based on a Misco computer parts invoice

16. Requirements Analysis 16. 16 Analysis Patterns - 2005b516.ppt © Copyright De Montfort University 2000 All Rights Reserved Parts Delivery Note Example DeliveryNote documentNumber accountNumber customerName despatchDate DeliveryNoteLine 1 1..* itemCode quantityDespatch ed itemDescription quantityToFollow deliveryLocation v Based on a Misco parts delivery note

17. Requirements Analysis 16. 17 Analysis Patterns - 2005b516.ppt © Copyright De Montfort University 2000 All Rights Reserved How do these look as a pattern? Transaction number date calcOverLineItems Transaction-Line 1 1..* number date calcForMe v This abstracts some recurring attributes and operations in the examples

18. Requirements Analysis 16. 18 Analysis Patterns - 2005b516.ppt © Copyright De Montfort University 2000 All Rights Reserved Transaction-TransactionLineItem  This is Coad’s Transaction- TransactionLineItem pattern v Very common in business documents v Always look for the suggested attributes and operations - e.g. calcForMe for line items (Coad, 1997)

19. Requirements Analysis 16. 19 Analysis Patterns - 2005b516.ppt © Copyright De Montfort University 2000 All Rights Reserved Complex Analysis Patterns: Organisation Hierarchies v Another application for patterns v Consider an organisation that is divided into –Operating Units... – which are divided into regions... – which are divided into divisions... – which are divided into sales offices… v Draw a class diagram to represent this

20. Requirements Analysis 16. 20 Analysis Patterns - 2005b516.ppt © Copyright De Montfort University 2000 All Rights Reserved First Solution Operating Unit Region Division Sales Office

21. Requirements Analysis 16. 21 Analysis Patterns - 2005b516.ppt © Copyright De Montfort University 2000 All Rights Reserved Organisation Hierarchies v This describes the reality but is difficult to modify v Removal of a region would force a significant change to the model v A more flexible structure can be based on a reflexive (self) association

22. Requirements Analysis 16. 22 Analysis Patterns - 2005b516.ppt © Copyright De Montfort University 2000 All Rights Reserved Single Reflexive Hierarchy OperatingUnitRegionDivisionSalesOffice Organisation 1 parent subsidiary *

23. Requirements Analysis 16. 23 Analysis Patterns - 2005b516.ppt © Copyright De Montfort University 2000 All Rights Reserved Organisation Hierarchies v This model has further weaknesses v As it stands, it would permit a division to be part of a sales office v This could be overcome by introducing constraints at subclass level

24. Requirements Analysis 16. 24 Analysis Patterns - 2005b516.ppt © Copyright De Montfort University 2000 All Rights Reserved Modified Single Reflexive Hierarchy {parent must be a division}{parent must be an operating unit} {parent must be a region} UML Constraints UML’s Object Constraint Language (OCL) expresses constraints like these more formally. E.g: {self.parent.oclType=division} * OperatingUnitRegionDivisionSalesOffice Organisation 1 parent subsidiary

25. Requirements Analysis 16. 25 Analysis Patterns - 2005b516.ppt © Copyright De Montfort University 2000 All Rights Reserved Two Hierarchies v Now imagine each sales office has a “Product Service Team” v Product Service Teams report to both: – their sales office, and – their product division v I.e. there are two separate hierarchies

26. Requirements Analysis 16. 26 Analysis Patterns - 2005b516.ppt © Copyright De Montfort University 2000 All Rights Reserved Two Hierarchies Organisation * 1 sales parent sales subsidiary 1 product parent product subsidiary *

27. Requirements Analysis 16. 27 Analysis Patterns - 2005b516.ppt © Copyright De Montfort University 2000 All Rights Reserved Two Hierarchies v Again this works, but further constraints would need to be modeled v The practical limit of modelling is two hierarchies v More, and the structure becomes totally unwieldy v The next model provides greater flexibility

28. Requirements Analysis 16. 28 Analysis Patterns - 2005b516.ppt © Copyright De Montfort University 2000 All Rights Reserved OperatingUnit RegionDivision SalesOffice Organisation OrganisationStructure OrganisationStructureType TimePeriod Rule 1 Constrains 1 ExampleOf 1 AppliesTo 1 ParentOf 1 SubsidiaryOf * * * * *

29. Requirements Analysis 16. 29 Analysis Patterns - 2005b516.ppt © Copyright De Montfort University 2000 All Rights Reserved Multiple Hierarchies v This pattern is now truly generic v The class Organisation Structure Type permits an arbitrary number of hierarchies v The class Rule accommodates any necessary constraints v The class Time Period allows a structure to be valid for a defined period of time

30. Requirements Analysis 16. 30 Analysis Patterns - 2005b516.ppt © Copyright De Montfort University 2000 All Rights Reserved Fowler’s Accountability Pattern v This pattern abstracts the various accountability relationships in business, e.g. –supervisor-supervised –client-contractor –representative-represented –etc...

31. Requirements Analysis 16. 31 Analysis Patterns - 2005b516.ppt © Copyright De Montfort University 2000 All Rights Reserved Accountability Pattern Accountability Type Accountability Time Period Party Person Organization Commissioner Responsible * * 1 1 1 1 * *

32. Requirements Analysis 16. 32 Analysis Patterns - 2005b516.ppt © Copyright De Montfort University 2000 All Rights Reserved Summary v Introduced the concept of patterns v Considered an example from architecture v Shown how patterns can apply to many aspects of software development v Demonstrated a simple analysis pattern v Demonstrated a complex analysis pattern

33. Requirements Analysis 16. 33 Analysis Patterns - 2005b516.ppt © Copyright De Montfort University 2000 All Rights Reserved Further Reading Bennett, S. et al 2002 “Object Oriented Systems Analysis and Design Using UML” McGraw-Hill Coad, P. 1997“Object Models: Strategies, Patterns and Applications” (2nd Ed.) Yourdon Press Coplien, J. 1995“Pattern Languages of Program Design Vol 1” Addison Wesley Evitts, P. 2000 “A UML Pattern Language” Macmillan Fowler, M. 1997“Analysis Patterns: Reusable Object Models” Addison Wesley Gamma, E. 1995“Design Patterns: Elements of Reusable Object-Oriented Software” Addison Wesley Martin, R. 1995“Pattern Languages of Program Design Vol 3” Addison Wesley Vlissides, J. 1996 “Pattern Languages of Program Design Vol 2” Addison Wesley