Tutorial 2 – Pattern Representation

1. Tutorial 2 –Pattern Representation RJ Macasaet R&D Dept.

2. Outline • Overview of a requirements-based approach for representing micro-business patterns • Pattern Essentials • emergence • diagrams • tabulation • modes and instantiations • custom symbols

3. Get an idea of the approach from a general perspective Overview

4. I. Approach Identifying Common Requirements Identifying Varying Requirements Iterate Observation of Micro-businesses Plan, Develop, and Deploy Overview Start Yes Database Link Component Archive Pattern Archive Observe Micro-businesses Develop another micro-business software system? No Pattern Emergence Identify Common Requirements Describe Pattern Deploy System Diagram Pattern For common For varying Identify Varying Requirements Draft Implementation Plan Develop Components End

5. I. Approach Overview - Observation of Micro-businesses • List down goals and requirements of two or more micro-businesses. • Decompose goals into requirements [sample method: see next slide adapted from Kotonyaand Sommerville] • Divide requirements into: functional and non-functional.

6. Decompose goals into requirements –from Kotonya and Sommerville

7. I. Approach Overview - Identification of Common and Varying Requirements • Group the common requirements. The minimum number of common requirements to constitute a pattern is 2 (If there was nothing in common, there would be no pattern in the first place). • Identify uncommon requirements. • Tabulating the pattern helps in organizing the requirements (common and uncommon, to be discussed in the next section)

8. I. Approach Overview - Emergence of patterns in succeeding iterations • For every succeeding micro-business, the software developer does the same activities of observing and listing down requirements. The new list of requirements is compared to all other existing requirements. Similar and varying requirements are identified. Similar requirements are grouped as stated in the previous slide • If there are no similar requirements then software components are simply developed to satisify/satisfice the requirements.

9. I. Approach Overview - Extra Implementation Notes • Due to the complexity of NFRs, additional implementation notes are normally added by the software developer in order to satisfice the NFRs. Refer to the source publication for more details.

10. I. Approach Overview – Metamodel Goals Sub Goals satisfy/satisfice Micro-business Processes • Here we have the artefacts of the approach represented in a metamodel decompose satisfy/satisfice decompose Requirements Functional Requirements Non-Functional Requirements satisfy satisfice Components realize Patterns Specifications Structure

11. Learn how to make patterns and use them within the approach Pattern essentials

12. II. Pattern Essentials - emergence • Common requirements are grouped • The minimum number of common requirements to constitute a pattern is 2 • There are as many as n!/(k!(n-k)!) sub-patterns, where n is the number of common requirements in a pattern and k is the number of common requirements in a grouping • The next slide illustrates how common requirements are grouped into patterns (note: μb stands for micro-business)

13. Describe and represent these common requirements as one… Pattern “Record-Display Cash Sale” Text Description: (for requirements “record cash sale” and “display total cash sales”) Example: The user is able to record a cash sale and then display cash sale totals Diagram: (for the common requirements) Example: action: store [record] record cash sale end action: query database link start query total cash sales [query] display total cash sales end

14. II. Pattern Essentials - diagrams • The previous slide also shows a pattern diagram which is a visual representation of the requirements in terms of (business) processes. • We recommend using BPMN to illustrate the processes but other languages and notations such as UML, SysML, or DFDs may be used.

15. II. Pattern Essentials - tabulation • In order to tabulate a pattern, (a) requirement(s) must be transformed into a non-technical form, such as a question, i.e. Requirement: display available products online (μb side) Non-technical form: does the customer shop online? • This is done in order to group the requirements as shown in the table on the next slide

16. II. Pattern Essentials - tabulation • Refer to user guide or source publication for details

17. II. Pattern Essentials – modes and instantiations • A pattern is an abstracted concept and in order use it, it must be [done as] a mode and then [applied as] an instantiation. Process Pattern: place to shop Mode: website Instantiation: www.shop.com [done as] [applied as]

18. II. Pattern Essentials – labels • “P” labels are placed in business process activities corresponding to the modes of the requirements pattern

19. II. Pattern Essentials – custom symbols • The concept also applies when connecting SIGs as well. NFR Start “speed” Other Process Process Pattern: place to shop Mode: website [done as] Fast Server {measurement: Data Transfer Rate} [applied as] Instantiation: www.shop.com

20. Questions?email:rjmacasaet@pentathlonsystems.com