CSC/ECE 517 Fall 2009/wiki2 12 Schemes for Pattern Classification

Overview

Design patterns in software engineering is a time-tested reusable solution to recurring problems in software design. The origin of design patterns can be owed to the work of civil engineer Christopher Alexander, who documented his resolution to design issues in constructing buildings and towns[1]. About a decade and a half ago, software professional began to incorporate Alexanders ideas into guides for novice developer. From then on design patterns became increasingly popular.

Schemes for Pattern Classification

Gamma et al.

Design Patterns gained popularity with the book Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides published in 1995. In their work they used 2 criteria to categorize 23 design pattern[2].

• What does the pattern do?
  • Structural - These patterns deal with the composition of classes and their object.
  • Creational - These patterns deal with object creation.
  • Behavioral - These patterns deal with the interaction between classes and object and how they delegate responsibility.

• What is the scope of the pattern?
  • Class - The patterns deal with the relationships between classes and their subclasses. These are more static and fixed at compile time.
  • Object - These patterns deal with object relationship. They are more dynamic and can vary at runtime.

Purpose
Documentation problem	Specification/Labeling problem (ambiguous/ missing/ incorrect)		4, 13, 22, 25, 34, 79, 83, 99 , 321, 329 , 340, 346
	Instruction problem	Instruction unavailable or incorrect.	5, 20, 21,26, 123, 33, 338, 150
		Instruction difficult to comprehend/inconspicuous.	24, 43, 90, 236, 152
Standards Problem	Universal color-code/Signs not followed.		34, 89 129, 351
	Safety standards not implemented/ followed.		17 347, 350
	Inconsistent procedure		20, 36, 83137
	Inconsistent design		3, 4, 7, 12, 16, 21, 33, 53, 54 , 60, 63, 70, 73, 76, 79, 86 259
	Incorrect size		32, 14
Design Problems	Unnecessary complexity		38, 42, 44, 55 ,59, 73, 96, 117, 260 145, 152
	Inconsideration of different user classes		23, 91, 118, 119, 278, 279
	Inappropriate positioning		10, 15, 17, 19,26, 28, 29, 32, 37, 39, 40, 46, 48, 59,61,67, 71, 72, 74, 77, 78, 84, 97, 99, 100, 236, 258, 339, 2,14, 242,62, 92,101, 102, 104, 153, 169, 188, 205, 206, 214,322, 330 , 331,344 146,
	Design hindering intended use		2, 9, 11, 14, 18, 22, 35, 41, 257,58,62, 65, 75, 81, 87, 226, 227, 337, ,121, [1]122], 345
	Inappropriate resource usage		2, 14, 31, 64, 81, 98, 120, 317, 235
	Lack of feedback to user		26,121, [2]122], 95, 150
	Interlinked events leading to eventual problem		28, 30, 69
	Option problems	Too little options	5
		Numerous options	45, 70, 74, 83
		Indistinguishable differences between options	1, 27, 48, 79, 93, 96,139
Implementation Problems	Poor quality resources used		64,92, [3]124], 149
	Functionality problem	Missing/ inefficient functionality	6, 8, 88,57, 233, 235, 352
		Too many functionalities put together; creating ambiguity	69, 70, 293, 348
Safety issue	Due to Loss/Theft		36, 99, 335, 354, 219, 318, 236, 149
	Human safety missing		41, 66, 80, 223, 138, 147, 280, 350, 324
External Factors	Required tool missing		0, 35,84, 225
	Extrinsic Conditions disrupting intended behavior		85
	Pre-conceived notions of the user about the system act as a hindrance in using the system		228, 131