2003 SJSU -- CmpE L04-S1 Stable Design Patterns

Software Patterns

Dr. M.E. Fayad, Professor

Computer Engineering Department, Room #283I

College of Engineering

San José State University

One Washington Square

San José, CA 95192-0180

http://www.engr.sjsu.edu/~fayad

2003 SJSU – CmpE --- M.E. Fayad L04-S2 Stable Design Patterns

2

Lesson 4:Stable Design Patterns

2003 SJSU – CmpE --- M.E. Fayad L04-S3 Stable Design Patterns

Lesson Objectives

Objectives

3

Explore Stable Design Patterns Examine Stable Design Patterns Discuss the following Stable Design Patterns:

Account

Entry

Party

Trust

2003 SJSU – CmpE --- M.E. Fayad L04-S4 Stable Design Patterns

ProblemFIRST ABSTRACTION: Apply SSM concepts Define EBTs, BOs, and IOs Create SSM for the problemSECOND ABSTRACTION: Model each EBT using SSM concepts Build natural domain Stable Design

Pattern4

The concept of extracting patterns using software stability concepts

2003 SJSU – CmpE --- M.E. Fayad L04-S5 Stable Design Patterns

Timeless Notion Pattern Working Horse of the system Patterns Adaptability Patterns True Presentation of The Solution

Space Patterns Management Workflow Metaphor

Patterns Domain-Independent Patterns

5

Stable Design Patterns’ Properties

2003 SJSU – CmpE --- M.E. Fayad L04-S6 Stable Design Patterns

Contribute to Stable ArchitecturesCan be Used to Model a Better

Solution SpaceProvide True Solution ModelingSpecifies Hooks for ExtensionsEnhance Team Dynamic

6

Stable Design Patterns Advantages

2003 SJSU – CmpE --- M.E. Fayad L04-S7 Stable Design Patterns

Abstractions

Adaptation

Extensions

Customization

Integration7

Stable Design Patterns’ Challenges

2003 SJSU – CmpE --- M.E. Fayad L04-S8 Stable Design Patterns

It was not too long ago when the word “account” was merely used to indicate banking and financial accounts.

Today, the word “account” alone becomes a vague concept if it is not allied with a word related to a certain context. For instance, besides all of the traditional well-known business and banking accounts, today we have e-mail accounts, on-line shopping accounts, on-line learning accounts, subscription accounts, and many others kinds of accounts. 8

AnyAccount Pattern (1)

2003 SJSU – CmpE --- M.E. Fayad L04-S9 Stable Design Patterns

In the last decade, there were many patterns that have been developed to model the account problems. However, even though they are all aimed to model the same problem “the account problem”, and they are all developed based on the long experience of their developers; however, each pattern has its own structure, with noticeable differences from the others. 9

AnyAccount Pattern (2)

2003 SJSU – CmpE --- M.E. Fayad L04-S10 Stable Design Patterns

What might be surprising is that most of these different models are developed for the similar applications, which are usually monetary applications, and all are claimed to be working just fine in the project they where originally developed for.

Examples of different patterns that model the account

problem can be found in the following Ref:

[1] M. Fowler, “Analysis Patterns: Reusable Object Models”, Addison-Wesley, 1997.

[2] E. Fernandez, “ The Account Analysis Pattern” , PLoP 2000

[3] D. Hay, “Data model patterns”, Conventions of thought, Dorset House Publ., 1996 10

AnyAccount Pattern (3)

2003 SJSU – CmpE --- M.E. Fayad L04-S11 Stable Design Patterns

There are some fundamental questions still to answer: – Why do we have MANY different patterns that model single

problem? – Can we develop a pattern that capture the atomic account

notion, and thus can serve as a base for modeling any kind of accounts?

The objective of this lecture is to provide an answer to these questions by discussing and documenting the atomic pattern AnyAccount.

This pattern models the core knowledge of any account, making it easy to reuse this pattern and build on the top of it to model any kind of accounts rather than thinking of the same problem each time from scratch. 11

AnyAccount Pattern (4)

2003 SJSU – CmpE --- M.E. Fayad L04-S12 Stable Design Patterns

Pattern Name: AnyAccount This pattern is required to model the core

knowledge of any account without tied the pattern to a specific application or domain; hence the name AnyAccount is chosen.

Problem How to build an account model that can

capture the core knowledge of the account problem, and can be reused to model the account problem in any application? 12

AnyAccount Pattern (5)

2003 SJSU – CmpE --- M.E. Fayad L04-S13 Stable Design Patterns

Account problem spans a fairly wide range of applications and domains, which makes the task of capturing the core concept of the account problem more challenging than it might appears.

Even after extracting the common feature of different accounts types, the difficulty still resides in how these common features can be abstracted in such away that makes them still valid for all these wide applications. 13

Forces (1)

2003 SJSU – CmpE --- M.E. Fayad L04-S14 Stable Design Patterns

14

Forces (2)

Different accounts have some features that are not applies to other accounts types.

The challenge arises when such uncommon features are associated with classes that should exist in the atomic pattern (For instance: in credit card accounts, it is acceptable to have many authorized holders who share the same credit card account. While, student account in a university, for example, is solely belongs to him, and cannot be shared.

On the other hand, the account holder is an essential part in any account independent of the account application, whenever there is an account there should be a holder/holders for this account. In this case, how can we manage to model the holder in such a way that is appropriate for such situations?”

2003 SJSU – CmpE --- M.E. Fayad L04-S15 Stable Design Patterns

15

Pattern structure

Role_1<<IO>>

Role_2<<IO>>

Role_n<<IO>>

........

AnyParty<<Pattern-BO>>

Ownership<<Patterns-EBT>>

AnyAccount<<Pattern-BO>>

1..*has

partyownership

controls

1..*ownership

account

2003 SJSU – CmpE --- M.E. Fayad L04-S16 Stable Design Patterns

Classes Ownership. Represents the existence of the account.

There is no existing for the account without the existence of an Owner. Therefore, ownership is always present, whenever there is an account exists. Describes the ownership rules, and regulations to the account holder(s).

AnyAccount. Represents the account itself.

2. Patterns AnyParty. Represents the account handler(s). Party

can be a person, organization, a group with specific orientation 16

Participants

2003 SJSU – CmpE --- M.E. Fayad L04-S17 Stable Design Patterns

17

CRC Cards (1)

Ownership (Owning Controller)

Responsibility Collaboration

  Clients Server

Describes the ownership rules, and regulations to the account holder(s).

AnyParty defineRules()specify()contrast()evaluate()

 

2003 SJSU – CmpE --- M.E. Fayad L04-S18 Stable Design Patterns

18

CRC Cards (2)

 

AnyParty (Account holder)

Responsibility Collaboration

Access the account. Clients Server

OwnershipAnyAccount

access()approve()activate()grant() 

2003 SJSU – CmpE --- M.E. Fayad L04-S19 Stable Design Patterns

19

CRC Cards (3)

 

 

 

 

AnyAccount (Descriptor)

Responsibility Collaboration

Describes account terms and conditions.

Clients Server

-         AnyParty defineAccountR egulations()open()close()

 

2003 SJSU – CmpE --- M.E. Fayad L04-S20 Stable Design Patterns

AnyAccount pattern has developed in such away that makes its model captures the very basic structure of any account independent of specific applications in mind.

Consequently, this atomic pattern is expected to play a role in any application where any sort of account is required. 20

Applicability with Illustrated Examples (1)

2003 SJSU – CmpE --- M.E. Fayad L04-S21 Stable Design Patterns

Another feature that worth to illustrate in the applicability section, is how this atomic pattern can indeed form the core where other specific patterns can be built on its top.

For instance, by modeling the checking account as a standalone problem using the AnyAccount pattern we can build and document a new pattern called CheckingAccount pattern, which is domain-specific pattern, in contrast to the AnyAccount pattern, which is domain-neutral pattern.

21

Applicability with Illustrated Examples (2)

2003 SJSU – CmpE --- M.E. Fayad L04-S22 Stable Design Patterns

Simple Problem (1) Access account to the copy machine: Suppose that you have an account to access the copy machine in your school or work. This account is no more than a passport for you for using the copier. There are no entries in this case.

22

Applicability with Illustrated Examples (3)

2003 SJSU – CmpE --- M.E. Fayad L04-S23 Stable Design Patterns

23

Applicability with Illustrated Examples (4)

EBTs BOs IOs              

 

   

 

Student<<IO>>

CopyMachineAccount<<IO>>

AnyParty<<Pattern-BO>>

Ownership<<EBT>>

AnyAccount<<Pattern-BO>>

has 1..*

contols

1..*

account

ownership

ownership party

2003 SJSU – CmpE --- M.E. Fayad L04-S24 Stable Design Patterns

This simple problem shows how to use the “AnyAccount” pattern in the modeling of a simple copy machine account in one of the universities. Each student in the university has an account that he can use to access a central copy machine.

Other Comments on the solution: Where IOs, Application classes.

24

Applicability with Illustrated Examples (5)

2003 SJSU – CmpE --- M.E. Fayad L04-S25 Stable Design Patterns

Problem (2): Modeling a simple hotmail account This example shows how to integrate more than

one pattern to model larger problems. The aim of the problem is to utilize the two constructed patterns: the “AnyAccount”, and the “AnyEntry” patterns, in the modeling of a simple Hotmail Account.

it is important to note that this model is not complete; it is merely for demonstration purpose.

25

Applicability with Illustrated Examples (6)

2003 SJSU – CmpE --- M.E. Fayad L04-S26 Stable Design Patterns

26

Applicability with Illustrated Examples (7)

EBTs BOs IOs 

                         

 

   

 

EmailAccount<<IO>>

EmailUser<<IO>>

AnyParty<<Pattern-BO>>has 1..*

contols

1..*

ownership

ownership party

UnformatedEntry<<IO>>

FormatedEntry<<IO>>

AnyEntry<<Pattern-BO>>enters 1..*

recording entry

Ownership<<EBT>>

EmailMessage<<IO>>

AnyAccount<<Pattern-BO>>

Recording<<Patterns-EBT>>

1..*

inserts

2003 SJSU – CmpE --- M.E. Fayad L04-S27 Stable Design Patterns

1. T/F

a. Account Pattern is an analysis pattern.

b. Account pattern contains the core knowledge of any account without tied the pattern to a specific application or domain.

2. Use AnyAccount Pattern as a foundation to model the following concepts:

Trust, CheckingAccount, SavingAccount, contraAccount, DialUpAccount, DiscretionaryAccount, EscrowAccount, and IndividualRetirementAccount. 27

Discussion Questions

2003 SJSU – CmpE --- M.E. Fayad L04-S28 Stable Design Patterns

We will cover Behavior Modeling: Activity Diagrams, Sequence Diagrams, STDs, Object Interaction Diagrams (OIDs) or Object Collaboration Diagrams (OCDs).

Describe the following Models: STD, OID, OCD.

28

Questions for the Next Lecture