程序代写代做代考 database Java Drawing a Design Diagram

Drawing a Design Diagram
using the Business Object Notation (BON)
EECS3311 A & E: Software Design Fall 2020
CHEN-WEI WANG
Why a Design Diagram?
● SOURCE CODE is not an appropriate form for communication.
● Use a DESIGN DIAGRAM showing selective sets of important: ○ clusters (i.e., packages)
○ classes
○ architectural relations [ generic vs. non-generic ]
○ routines (queries and commands) [ client-supplier vs. inheritance ]
[ deferred vs. effective ]
[ deferred vs. effective vs. redefined ]
○ contracts
● Your design diagram is called an abstraction of your system:
[ precondition vs. postcondition vs. class invariant ]
○ Being selective on what to show, filtering out irrelevant details ○ Presenting contractual specification in a mathematical form
(e.g., ∀ instead of across . . . all . . . end). 3 of 26
Learning Objectives
● Purpose of a Design Diagram: an Abstraction of Your Design ● Architectural Relation: Client-Supplier vs. Inheritance
● Presenting a class: Compact vs. Detailed
● Denoting a Class or Feature: Deferred vs. Effective
2 of 26
Classes:
Detailed View vs. Compact View (1)
●
●
shows a selection of: ○ features (queries and/or commands)
Detailed view
○ contracts (class invariant and feature pre-post-conditions)
○ Use the detailed view if readers of your design diagram should
know such details of a class.
e.g., Classes critical to your design or implementation
○ Use the compact view if readers should not be bothered with such details of a class.
e.g., Minor “helper” classes of your design or implementation e.g., Library classes (e.g., ARRAY, LINKED LIST, HASH TABLE)
Compact view
shows only the class name.
4 of 26

Classes:
Detailed View vs. Compact View (2)
Detailed View
FOO
feat􏰋re — 􏰳 A, B, 􏰴 􏰵
— 􏰈􏰉􏰊􏰅􏰋􏰆􏰉􏰎 􏰉􏰣􏰨􏰇􏰆􏰅􏰉􏰧 􏰅􏰇 􏰏􏰦􏰊􏰎􏰎􏰉􏰎 A, B, 􏰊􏰐􏰧 􏰴
feat􏰋re — 􏰳 NONE 􏰵 — 􏰨􏰆􏰍􏰗􏰊􏰅􏰉 􏰈􏰉􏰊􏰅􏰋􏰆􏰉􏰎
in􏰗arian􏰅
in􏰗_1: 0 < 􏰙􏰊􏰦􏰊􏰐􏰏􏰉 < 1,000,000 5 of 26 Compact View FOO Classes: Generic vs. Non-Generic ● A class is generic if it declares at least one type parameters. ○ Collection classes are generic: ARRAY[G], HASH TABLE[G, H], etc. ○ Type parameter(s) of a class may or may not be instantiated: HA􏰜H􏰪􏰕AB􏰮E􏰑G, H􏰖 􏰸􏰯􏰪􏰕AB􏰮E􏰪1􏰑􏰜􏰕􏰝􏰞􏰔G, 􏰞􏰔􏰕EGE􏰝􏰖 􏰸􏰯􏰪􏰕AB􏰮E􏰪2􏰑􏰹E􏰝􏰜􏰒􏰔, 􏰞􏰔􏰕EGE􏰝􏰖 ○ If necessary, present a generic class in the detailed form: DATABASE􏰑G􏰖+ feature -- 􏰎􏰇􏰛􏰉 􏰨􏰋􏰙􏰦􏰍􏰏 􏰈􏰉􏰊􏰅􏰋􏰆􏰉􏰎 􏰘􏰉􏰆􏰉 feature -- 􏰳 NONE 􏰵 -- 􏰍􏰛􏰨: ARRAY􏰑G􏰖 in􏰗arian􏰅 -- 􏰎􏰇􏰛􏰉 􏰏􏰦􏰊􏰎􏰎 􏰍􏰐􏰗􏰊􏰆􏰍􏰊􏰐􏰅 􏰘􏰉􏰆􏰉 M􏰯􏰪DB􏰪1􏰑STRING􏰖+ feature -- 􏰎􏰇􏰛􏰉 􏰨􏰋􏰙􏰦􏰍􏰏 􏰈􏰉􏰊􏰅􏰋􏰆􏰉􏰎 􏰘􏰉􏰆􏰉 feature -- 􏰳 NONE 􏰵 -- 􏰍􏰛􏰨: ARRAY􏰑STRING􏰖 in􏰗arian􏰅 -- 􏰎􏰇􏰛􏰉 􏰏􏰦􏰊􏰎􏰎 􏰍􏰐􏰗􏰊􏰆􏰍􏰊􏰐􏰅 􏰘􏰉􏰆􏰉 M􏰯􏰪DB􏰪2􏰑PERSON􏰖+ feature -- 􏰎􏰇􏰛􏰉 􏰨􏰋􏰙􏰦􏰍􏰏 􏰈􏰉􏰊􏰅􏰋􏰆􏰉􏰎 􏰘􏰉􏰆􏰉 feature -- 􏰳 NONE 􏰵 -- 􏰍􏰛􏰨: ARRAY􏰑PER􏰜ON􏰖 in􏰗arian􏰅 -- 􏰎􏰇􏰛􏰉 􏰏􏰦􏰊􏰎􏰎 􏰍􏰐􏰗􏰊􏰆􏰍􏰊􏰐􏰅 􏰘􏰉􏰆􏰉 ● A class is non-generic if it declares no type parameters. 7 of 26 Contracts: Mathematical vs. Programming ○ When presenting the detailed view of a class, you should include contracts of features which you judge as important. ○ Consider an array-based linear container: A􏰝􏰝A􏰯ED􏰪CON􏰕AINE􏰝+ 􏰈􏰉􏰊􏰅􏰋􏰆􏰉 -- Q􏰋􏰉􏰆􏰍􏰉􏰎 c􏰇􏰋􏰐􏰅+: IN􏰕EGER -- N􏰋􏰛􏰙􏰉􏰆 􏰇􏰈 􏰍􏰅􏰉􏰛􏰎 􏰎􏰅􏰇􏰆􏰉􏰧 􏰍􏰐 􏰅􏰘􏰉 􏰏􏰇􏰐􏰅a􏰍􏰐􏰉􏰆 􏰈􏰉􏰊􏰅􏰋􏰆􏰉 -- C􏰇􏰛􏰛a􏰐d􏰎 a􏰎􏰎􏰍􏰫􏰐_a􏰅+ (􏰍: IN􏰕EGER; 􏰎: 􏰜􏰕RING) -- C􏰘a􏰐􏰫􏰉 􏰅􏰘􏰉 􏰗a􏰦􏰋􏰉 a􏰅 􏰨􏰇􏰎􏰍􏰅􏰍􏰇􏰐 '􏰍' 􏰅􏰇 '􏰎'. 􏰆􏰉􏰢􏰋􏰍􏰆􏰉 􏰗a􏰦􏰍􏰧_􏰍􏰐􏰧􏰉􏰣: 1 􏰩 􏰍 􏰩 c􏰇􏰋􏰐􏰅 􏰉􏰐􏰎􏰋􏰆􏰉 􏰎􏰍􏰶􏰉_􏰋􏰐􏰏􏰘a􏰐􏰫􏰉􏰧: 􏰍􏰛􏰨.c􏰇􏰋􏰐􏰅 = (􏰇􏰦􏰧 􏰍􏰛􏰨.􏰅􏰡􏰍􏰐).c􏰇􏰋􏰐􏰅 􏰍􏰅􏰉􏰛_a􏰎􏰎􏰍􏰫􏰐􏰉􏰧: 􏰍􏰛􏰨[􏰍] 􏰥 􏰎 􏰇􏰅􏰘􏰉􏰆􏰎_􏰋􏰐􏰏􏰘a􏰐􏰫􏰉􏰧: ∀􏰠 : 1 􏰩 􏰠 􏰩 􏰍􏰛􏰨.c􏰇􏰋􏰐􏰅 : 􏰠 􏰬 􏰍 ⇒􏰍􏰛􏰨[􏰠] 􏰥 (􏰇􏰦􏰧 􏰍􏰛􏰨.􏰅􏰡􏰍􏰐) [􏰠] 􏰈􏰉􏰊􏰅􏰋􏰆􏰉 -- 􏰳 NONE 􏰵 􏰍􏰛􏰨+: ARRA􏰯[􏰜􏰕RING] -- I􏰛􏰨􏰦􏰉􏰛􏰉􏰐􏰅a􏰅􏰍􏰇􏰐 􏰇􏰈 a􏰐 a􏰆􏰆a􏰷􏰉􏰧-􏰏􏰇􏰐􏰅a􏰍􏰐􏰉􏰆 in􏰗arian􏰅 􏰏􏰇􏰐􏰎􏰍􏰎􏰅􏰉􏰐􏰏􏰷: 􏰍􏰛􏰨.c􏰇􏰋􏰐􏰅 = c􏰇􏰋􏰐􏰅 ● Atagshouldbeincludedforeachcontract. ● Usemathematicalsymbols(e.g.,∀,∃,≤)insteadofprogramming 6 of 26 symbols (e.g., across ... all ..., across ... some ..., <=). Deferred vs. Effective means unimplemented (≈ abstract in Java) means implemented Deferred Effective 8 of 26 Classes: Deferred vs. Effective ● A deferred class has at least one feature unimplemented. ○ A deferred class may only be used as a static type (for declaration), but cannot be used as a dynamic type. ○ e.g., By declaring list: LIST[INTEGER] (where LIST is a deferred class), it is invalid to write: ● create list.make ● create {LIST[INTEGER]} list.make ● An effective class has all features implemented. ○ An effective class may be used as both static and dynamic types. ○ e.g., By declaring list: LIST[INTEGER], it is valid to write: ● create {LINKED LIST[INTEGER]} list.make ● create {ARRAYED LIST[INTEGER]} list.make where LINKED LIST and ARRAYED LIST are both effective descendants of LIST. 9 of 26 Features: Deferred, Effective, Redefined (2) ● An effective feature implements some inherited deferred feature. ● A descendant class may still later re-implement this feature. 11 of 26 class DATABASE_V1[G] inherit DATABASE[G] feature -- Queries search (g: G): BOOLEAN -- Perform a linear search on the database. do end end Features: Deferred, Effective, Redefined (1) A deferred feature is declared with its header only (i.e., name, parameters, return type). ○ The word “deferred” means a descendant class would later implement this feature. ○ The resident class of the deferred feature must also be deferred. deferred class DATABASE[G] feature -- Queries search (g: G): BOOLEAN -- Does item ‘g‘ exist in database? deferred end end 10 of 26 Features: Deferred, Effective, Redefined (3) ● A redefined feature re-implements some inherited effective feature. class DATABASE_V2[G] inherit DATABASE_V1[G] redefine search end feature -- Queries search (g: G): BOOLEAN -- Perform a binary search on the database. do end end ● A descendant class may still later re-implement this feature. 12 of 26 Classes: Deferred vs. Effective (2.1) Append a star * to the name of a deferred class or feature. Append a plus + to the name of an effective class or feature. Append two pluses ++ to the name of a redefined feature. ● Deferred or effective classes may be in the compact form: LI􏰜􏰕􏰑G􏰖* LI􏰜􏰕􏰑LI􏰜􏰕􏰑PER􏰜ON􏰖􏰖* DA􏰕ABA􏰜E􏰑G􏰖* 13 of 26 LINKED􏰪LI􏰜􏰕􏰑G􏰖+ LINKED􏰪LI􏰜􏰕􏰑IN􏰕EGER􏰖+ DA􏰕ABA􏰜E􏰪􏰺1􏰑G􏰖+ ARRA􏰯ED􏰪LI􏰜􏰕􏰑G􏰖+ ARRA􏰯ED􏰪LI􏰜􏰕􏰑G􏰖+ DA􏰕ABA􏰜E􏰪􏰺2􏰑G􏰖+ Class Relations: Inheritance (1) ● An inheritance hierarchy is formed using red arrows. ○ Arrow’s origin indicates the child/descendant class. ○ Arrow’s destination indicates the parent/ancestor class. ● You may choose to present each class in an inheritance hierarchy in either the detailed form or the compact form: * LIST[G􏰖 MY 􏰪LIST 􏰪INTERFACE[G]* feat􏰋re -- 􏰎􏰇􏰛􏰉 􏰨􏰋􏰙􏰦􏰍􏰏 􏰈􏰉􏰊􏰅􏰋􏰆􏰉􏰎 􏰘􏰉􏰆􏰉 feat􏰋re -- 􏰳 NONE 􏰵 -- 􏰎􏰇􏰛􏰉 􏰍􏰛􏰨􏰦􏰉􏰛􏰉􏰐􏰅􏰊􏰅􏰍􏰇􏰐 􏰈􏰉􏰊􏰅􏰋􏰆􏰉􏰎 􏰘􏰉􏰆􏰉 in􏰗arian􏰅 -- 􏰎􏰇􏰛􏰉 􏰏􏰦􏰊􏰎􏰎 􏰍􏰐􏰗􏰊􏰆􏰍􏰊􏰐􏰅 􏰘􏰉􏰆􏰉 ++ MY 􏰪LIST 􏰪IMP􏰪ONE[G􏰖+ MY 􏰪LIST 􏰪IMP􏰪TWO[G􏰖+ 15 of 26 Classes: Deferred vs. Effective (2.2) Append a star * to the name of a deferred class or feature. Append a plus + to the name of an effective class or feature. Append two pluses ++ to the name of a redefined feature. ● Deferred or effective classes may be in the detailed form: DA􏰕ABA􏰜E􏰑􏰟􏰖* DA􏰕ABA􏰜E􏰪􏰺1􏰑􏰟􏰖+ DA􏰕ABA􏰜E􏰪􏰺2􏰑􏰟􏰖+ 􏰈􏰉􏰊􏰅􏰋􏰆􏰉 􏰳􏰔􏰒􏰔E􏰵 -- I􏰛􏰨􏰦􏰉􏰛􏰉􏰐􏰅􏰊􏰅􏰍􏰇􏰐 􏰧􏰊􏰅􏰊: A􏰝􏰝A􏰯􏰑G􏰖 􏰈􏰉􏰊􏰅􏰋􏰆􏰉 -- C􏰇􏰛􏰛􏰊􏰐􏰧􏰎 􏰊􏰧􏰧􏰪􏰍􏰅􏰉􏰛* (􏰫: G) -- A􏰧􏰧 􏰐􏰉􏰡 􏰍􏰅􏰉􏰛 􏰻􏰫􏰻 􏰍􏰐􏰅􏰇 􏰧􏰊􏰅􏰊􏰙􏰊􏰎􏰉. 􏰆􏰉􏰢􏰋􏰍􏰆􏰉 􏰐􏰇􏰐_e􏰣i􏰎􏰅i􏰐g_i􏰅e􏰛: 􏰼 􏰉􏰣􏰍􏰎􏰅􏰎 (􏰫) 􏰉􏰐􏰎􏰋􏰆􏰉 􏰎i􏰶e_i􏰐c􏰆e􏰛e􏰐􏰅ed: 􏰏􏰇􏰋􏰐􏰅 = 􏰇􏰦􏰧 􏰏􏰇􏰋􏰐􏰅 + 1 i􏰅e􏰛_added: 􏰉􏰣􏰍􏰎􏰅􏰎 (􏰫) 􏰈􏰉􏰊􏰅􏰋􏰆􏰉 -- 􏰽􏰋􏰉􏰆􏰍􏰉􏰎 􏰏􏰇􏰋􏰐􏰅+: I􏰔􏰕EGE􏰝 -- N􏰋􏰛􏰙􏰉􏰆 􏰇􏰈 􏰍􏰅􏰉􏰛􏰎 􏰎􏰅􏰇􏰆􏰉􏰧 􏰍􏰐 􏰧􏰊􏰅􏰊􏰙􏰊􏰎􏰉 􏰉􏰐􏰎􏰋􏰆􏰉 c􏰇􏰆􏰆ec􏰅_􏰆e􏰎􏰋l􏰅: 􏰝􏰉􏰎􏰋􏰦􏰅 = 􏰧􏰊􏰅􏰊.􏰏􏰇􏰋􏰐􏰅 􏰉􏰣􏰍􏰎􏰅􏰎* (􏰫: G): B􏰒􏰒LEA􏰔 -- D􏰇􏰉􏰎 􏰍􏰅􏰉􏰛 􏰻􏰫􏰻 􏰉􏰣􏰍􏰎􏰅 􏰍􏰐 􏰧􏰊􏰅􏰊􏰙􏰊􏰎􏰉? 􏰉􏰐􏰎􏰋􏰆􏰉 c􏰇􏰆􏰆ec􏰅_􏰆e􏰎􏰋l􏰅: 􏰝􏰉􏰎􏰋􏰦􏰅 = (∃􏰍 : 1 􏰩 􏰍 􏰩 􏰏􏰇􏰋􏰐􏰅 : 􏰧􏰊􏰅􏰊􏰑􏰍􏰖 􏰥 􏰫) 􏰈􏰉􏰊􏰅􏰋􏰆􏰉 􏰳􏰔􏰒􏰔E􏰵 -- I􏰛􏰨􏰦􏰉􏰛􏰉􏰐􏰅􏰊􏰅􏰍􏰇􏰐 􏰧􏰊􏰅􏰊: A􏰝􏰝A􏰯􏰑G􏰖 􏰈􏰉􏰊􏰅􏰋􏰆􏰉 -- C􏰇􏰛􏰛􏰊􏰐􏰧􏰎 􏰊􏰧􏰧􏰪􏰍􏰅􏰉􏰛+ (􏰫: G) -- A􏰨􏰨􏰉􏰐􏰧 􏰐􏰉􏰡 􏰍􏰅􏰉􏰛 􏰻􏰫􏰻 􏰍􏰐􏰅􏰇 􏰉􏰐􏰧 􏰇􏰈 􏰻􏰧􏰊􏰅􏰊􏰻. 􏰈􏰉􏰊􏰅􏰋􏰆􏰉 -- 􏰽􏰋􏰉􏰆􏰍􏰉􏰎 􏰏􏰇􏰋􏰐􏰅+: I􏰔􏰕EGE􏰝 -- N􏰋􏰛􏰙􏰉􏰆 􏰇􏰈 􏰍􏰅􏰉􏰛􏰎 􏰎􏰅􏰇􏰆􏰉􏰧 􏰍􏰐 􏰧􏰊􏰅􏰊􏰙􏰊􏰎􏰉 􏰉􏰣􏰍􏰎􏰅􏰎+ (􏰫: G): B􏰒􏰒LEA􏰔 -- 􏰹􏰉􏰆􏰈􏰇􏰆􏰛 􏰊 􏰦􏰍􏰐􏰉􏰊􏰆 􏰎􏰉􏰊􏰆􏰏􏰘 􏰇􏰐 􏰻􏰧􏰊􏰅􏰊􏰻 􏰊􏰆􏰆􏰊􏰷. 􏰈􏰉􏰊􏰅􏰋􏰆􏰉 􏰳􏰔􏰒􏰔E􏰵 -- I􏰛􏰨􏰦􏰉􏰛􏰉􏰐􏰅􏰊􏰅􏰍􏰇􏰐 􏰧􏰊􏰅􏰊: A􏰝􏰝A􏰯􏰑G􏰖 􏰈􏰉􏰊􏰅􏰋􏰆􏰉 -- C􏰇􏰛􏰛􏰊􏰐􏰧􏰎 􏰊􏰧􏰧􏰪􏰍􏰅􏰉􏰛++ (􏰫: G) -- I􏰐􏰎􏰉􏰆􏰅 􏰐􏰉􏰡 􏰍􏰅􏰉􏰛 􏰻􏰫􏰻 􏰍􏰐􏰅􏰇 􏰅􏰘􏰉 􏰆􏰍􏰫􏰘􏰅 􏰎􏰦􏰇􏰅 􏰇􏰈 􏰻􏰧􏰊􏰅􏰊􏰻. 􏰈􏰉􏰊􏰅􏰋􏰆􏰉 -- 􏰽􏰋􏰉􏰆􏰍􏰉􏰎 􏰏􏰇􏰋􏰐􏰅+: I􏰔􏰕EGE􏰝 -- N􏰋􏰛􏰙􏰉􏰆 􏰇􏰈 􏰍􏰅􏰉􏰛􏰎 􏰎􏰅􏰇􏰆􏰉􏰧 􏰍􏰐 􏰧􏰊􏰅􏰊􏰙􏰊􏰎􏰉 􏰉􏰣􏰍􏰎􏰅􏰎++ (􏰫: G): B􏰒􏰒LEA􏰔 -- 􏰹􏰉􏰆􏰈􏰇􏰆􏰛 􏰊 􏰙􏰍􏰐􏰊􏰆􏰷 􏰎􏰉􏰊􏰆􏰏􏰘 􏰇􏰐 􏰻􏰧􏰊􏰅􏰊􏰻 􏰊􏰆􏰆􏰊􏰷. 􏰍􏰐􏰗􏰊􏰆􏰍􏰊􏰐􏰅 􏰎􏰇􏰆􏰅ed_da􏰅a: ∀􏰍 : 1 􏰩 􏰍 < 􏰏􏰇􏰋􏰐􏰅 : 􏰧􏰊􏰅􏰊􏰑􏰍􏰖 < 􏰧􏰊􏰅􏰊􏰑􏰍 + 1􏰖 14 of 26 Class Relations: Inheritance (2) More examples (emphasizing different aspects of DATABASE): Inheritance Hierarchy Features being (Re-)Implemented DA􏰕ABA􏰜E􏰑􏰟􏰖* DA􏰕ABA􏰜E􏰪􏰺1􏰑􏰟􏰖+ DA􏰕ABA􏰜E􏰪􏰺2􏰑􏰟􏰖+ DA􏰕ABA􏰜E􏰑G􏰖* 􏰈􏰉􏰊􏰅􏰋􏰆􏰉 􏰳􏰔􏰒􏰔E􏰵 -- 􏰞􏰛􏰨􏰦􏰉􏰛􏰉􏰐􏰅􏰊􏰅􏰍􏰇􏰐 􏰧􏰊􏰅􏰊: A􏰝􏰝A􏰯􏰑G􏰖 􏰈􏰉􏰊􏰅􏰋􏰆􏰉 -- C􏰇􏰛􏰛􏰊􏰐􏰧􏰎 􏰊􏰧􏰧􏰪􏰍􏰅􏰉􏰛* (􏰫: G) -- A􏰧􏰧 􏰐􏰉􏰡 􏰍􏰅􏰉􏰛 􏰻􏰫􏰻 􏰍􏰐􏰅􏰇 􏰧􏰊􏰅􏰊􏰙􏰊􏰎􏰉. 􏰆􏰉􏰢􏰋􏰍􏰆􏰉 􏰐􏰇􏰐_e􏰣i􏰎􏰅i􏰐g_i􏰅e􏰛: 􏰼 􏰉􏰣􏰍􏰎􏰅􏰎 (􏰫) 􏰉􏰐􏰎􏰋􏰆􏰉 􏰎i􏰶e_i􏰐c􏰆e􏰛e􏰐􏰅ed: 􏰏􏰇􏰋􏰐􏰅 = 􏰇􏰦􏰧 􏰏􏰇􏰋􏰐􏰅 + 1 i􏰅e􏰛_added: 􏰉􏰣􏰍􏰎􏰅􏰎 (􏰫) 􏰈􏰉􏰊􏰅􏰋􏰆􏰉 -- 􏰽􏰋􏰉􏰆􏰍􏰉􏰎 􏰏􏰇􏰋􏰐􏰅+: I􏰔􏰕EGE􏰝 -- 􏰔􏰋􏰛􏰙􏰉􏰆 􏰇􏰈 􏰍􏰅􏰉􏰛􏰎 􏰎􏰅􏰇􏰆􏰉􏰧 􏰍􏰐 􏰧􏰊􏰅􏰊􏰙􏰊􏰎􏰉 􏰉􏰐􏰎􏰋􏰆􏰉 c􏰇􏰆􏰆ec􏰅_􏰆e􏰎􏰋l􏰅: 􏰝􏰉􏰎􏰋􏰦􏰅 = 􏰧􏰊􏰅􏰊.􏰏􏰇􏰋􏰐􏰅 􏰉􏰣􏰍􏰎􏰅􏰎* (􏰫: G): B􏰒􏰒LEA􏰔 -- D􏰇􏰉􏰎 􏰍􏰅􏰉􏰛 􏰻􏰫􏰻 􏰉􏰣􏰍􏰎􏰅 􏰍􏰐 􏰧􏰊􏰅􏰊􏰙􏰊􏰎􏰉? 􏰉􏰐􏰎􏰋􏰆􏰉 c􏰇􏰆􏰆ec􏰅_􏰆e􏰎􏰋l􏰅: 􏰝􏰉􏰎􏰋􏰦􏰅 = (∃􏰍 : 1 􏰩 􏰍 􏰩 􏰏􏰇􏰋􏰐􏰅 : 􏰧􏰊􏰅􏰊􏰑􏰍􏰖 􏰥 􏰫) DA􏰕ABA􏰜E􏰪􏰺1􏰑G􏰖+ DA􏰕ABA􏰜E􏰪􏰺2􏰑G􏰖+ 􏰈􏰉􏰊􏰅􏰋􏰆􏰉 􏰳􏰔􏰒􏰔E􏰵 -- 􏰞􏰛􏰨􏰦􏰉􏰛􏰉􏰐􏰅􏰊􏰅􏰍􏰇􏰐 􏰧􏰊􏰅􏰊: A􏰝􏰝A􏰯􏰑G􏰖 􏰈􏰉􏰊􏰅􏰋􏰆􏰉 -- C􏰇􏰛􏰛􏰊􏰐􏰧􏰎 􏰊􏰧􏰧􏰪􏰍􏰅􏰉􏰛++ (􏰫: G) -- 􏰞􏰐􏰎􏰉􏰆􏰅 􏰐􏰉􏰡 􏰍􏰅􏰉􏰛 􏰻􏰫􏰻 􏰍􏰐􏰅􏰇 􏰅􏰘􏰉 􏰆􏰍􏰫􏰘􏰅 􏰎􏰦􏰇􏰅 􏰇􏰈 􏰻􏰧􏰊􏰅􏰊􏰻. 􏰈􏰉􏰊􏰅􏰋􏰆􏰉 -- 􏰽􏰋􏰉􏰆􏰍􏰉􏰎 􏰏􏰇􏰋􏰐􏰅+: I􏰔􏰕EGE􏰝 -- 􏰔􏰋􏰛􏰙􏰉􏰆 􏰇􏰈 􏰍􏰅􏰉􏰛􏰎 􏰎􏰅􏰇􏰆􏰉􏰧 􏰍􏰐 􏰧􏰊􏰅􏰊􏰙􏰊􏰎􏰉 􏰉􏰣􏰍􏰎􏰅􏰎++ (􏰫: G): B􏰒􏰒LEA􏰔 -- 􏰹􏰉􏰆􏰈􏰇􏰆􏰛 􏰊 􏰙􏰍􏰐􏰊􏰆􏰷 􏰎􏰉􏰊􏰆􏰏􏰘 􏰇􏰐 􏰻􏰧􏰊􏰅􏰊􏰻 􏰊􏰆􏰆􏰊􏰷. 􏰍􏰐􏰗􏰊􏰆􏰍􏰊􏰐􏰅 16 of 26 􏰎􏰇􏰆􏰅ed_da􏰅a: ∀􏰍 : 1 􏰩 􏰍 < 􏰏􏰇􏰋􏰐􏰅 : 􏰧􏰊􏰅􏰊􏰑􏰍􏰖 < 􏰧􏰊􏰅􏰊􏰑􏰍 + 1􏰖 Class Relations: Client-Supplier (1) ● A exists between two classes: one (the client) uses the service of another (the supplier). ● Programmatically, there is CS relation if in class CLIENT there client-supplier (CS) relation is a variable declaration . ○ A variable may be an attribute, a parameter, or a local variable. s1: SUPPLIER ● A green arrow is drawn between the two classes. ○ Arrow’s origin indicates the client class. ○ Arrow’s destination indicates the supplier class. ○ Above the arrow there should be a label indicating the supplier name (i.e., variable name). ○ In the case where supplier is a routine, indicate after the label name if it is deferred (*), effective (+), or redefined (++). 17 of 26 Class Relations: Client-Supplier (2.2.1) If STRING is to be emphasized, label is , where . . . denotes the supplier class STRING being pointed to. DA􏰕ABA􏰜E+ 􏰈􏰉􏰊􏰅􏰋􏰆􏰉 􏰊􏰧􏰧􏰪􏰐􏰊􏰛􏰉+ (􏰐􏰐: 􏰜􏰕􏰝ING) -- Add 􏰐a􏰛􏰉 `􏰐􏰐` 􏰍􏰐􏰅􏰇 da􏰅aba􏰎􏰉. 􏰆􏰉􏰢􏰋􏰍􏰆􏰉 ... 􏰉􏰐􏰎􏰋􏰆􏰉 ... 􏰐􏰊􏰛􏰉􏰪􏰉􏰣􏰍􏰎􏰅􏰎+ (􏰐: 􏰜􏰕􏰝ING): BOOLEAN -- D􏰇􏰉􏰎 􏰐a􏰛􏰉 `􏰐` 􏰉􏰣􏰍􏰎􏰅? 􏰆􏰉􏰢􏰋􏰍􏰆􏰉 ... 􏰉􏰐􏰎􏰋􏰆􏰉 ... in􏰗ariant ... 19 of 26 data+: ARRA􏰯􏰑...􏰖 􏰋 n, nn data: ARRAY[...] + 􏰜􏰕􏰝􏰞􏰔G 􏰓􏰕􏰞􏰮􏰞􏰕􏰞E􏰜+ 􏰈􏰉􏰊􏰅􏰋􏰆􏰉 􏰎􏰉􏰊􏰆􏰏􏰘+ (􏰊: A􏰝􏰝A􏰯􏰑􏰜􏰕􏰝ING􏰖; 􏰐: 􏰜􏰕􏰝ING): BOOLEAN -- D􏰇􏰉􏰎 􏰐a􏰛􏰉 `􏰐` 􏰉􏰣􏰍􏰎􏰅 􏰍􏰐 a􏰆􏰆a􏰷 `a`? require ... 􏰉􏰐􏰎􏰋􏰆􏰉 ... Class Relations: Client-Supplier (2.1) class DATABASE feature {NONE} -- implementation data: ARRAY[STRING] feature -- Commands add_name (nn: STRING) -- Add name ‘nn‘ to database. require ... do ... ensure ... end name_exists (n: STRING): BOOLEAN -- Does name ‘n‘ exist in database? require ... local u: UTILITIES do ... ensure ... end invariant ... end ○ Query indicates two suppliers: STRING and ARRAY. class UTILITIES feature -- Queries search (a: ARRAY[STRING]; n: STRING): BOOLEAN -- Does name ‘n‘ exist in array ‘a‘? require ... do ... ensure ... end end data: ARRAY[STRING] ○ Parameters nn and n may have an arrow with label , pointing to the STRING class. ○ Local variable u may have an arrow with label , pointing to the 18 of 26UTILITIES class. nn, n u Class Relations: Client-Supplier (2.2.2) If ARRAY is to be emphasized, label is . The supplier’s name should be complete: ARRAY[STRING] data 􏰾A􏰕ABA􏰜􏰿+ 􏰈􏰉􏰊􏰅􏰋􏰆􏰉 􏰊􏰧􏰧􏰪􏰐􏰊􏰛􏰉+ (􏰐􏰐: 􏰜􏰕􏰝ING) -- Add 􏰐a􏰛􏰉 `􏰐􏰐` 􏰍􏰐􏰅􏰇 da􏰅aba􏰎􏰉. 􏰆􏰉􏰢􏰋􏰍􏰆􏰉 ... 􏰉􏰐􏰎􏰋􏰆􏰉 ... 􏰐􏰊􏰛􏰉􏰪􏰉􏰣􏰍􏰎􏰅􏰎+ (􏰐: 􏰜􏰕􏰝ING): BOOLEAN -- D􏰇􏰉􏰎 􏰐a􏰛􏰉 `􏰐` 􏰉􏰣􏰍􏰎􏰅? 􏰆􏰉􏰢􏰋􏰍􏰆􏰉 ... 􏰉􏰐􏰎􏰋􏰆􏰉 ... in􏰗arian􏰅 ... 􏰧􏰊􏰅􏰊+ n, nn 􏰋 + A􏰝􏰝A􏰯􏰑􏰜􏰕􏰝􏰞􏰔􏰟􏰖 + 􏰜􏰕􏰝􏰞􏰔􏰟 + 􏰓􏰕􏰞􏰮􏰞􏰕􏰞E􏰜 20 of 26 Class Relations: Client-Supplier (3.1) Known: The deferred class LIST has two effective descendants ARRAY LIST and LINKED LIST). ● DESIGN ONE: ● DESIGN TWO: Question: Which design is better? [ DESIGN TWO ] Rationale: Program to the interface, not the implementation. 21 of 26 class DATABASE_V1 feature {NONE} -- implementation imp: ARRAYED_LIST[PERSON] ... -- more features and contracts end class DATABASE_V2 feature {NONE} -- implementation imp: LIST[PERSON] ... -- more features and contracts end Class Relations: Client-Supplier (3.2.2) Alternatively, we may focus on the LIST supplier class, which in this case helps us judge which design is better. DATABASE􏰪􏰺1+ feat􏰋re imp+ -- 􏰎􏰇􏰛􏰉 􏰨􏰋􏰙􏰦􏰍􏰏 􏰈􏰉􏰊􏰅􏰋􏰆􏰉􏰎 􏰘􏰉􏰆􏰉 feat􏰋re -- 􏰳 NONE 􏰵 -- 􏰎􏰇􏰛􏰉 􏰍􏰛􏰨􏰦􏰉􏰛􏰉􏰐􏰅􏰊􏰅􏰍􏰇􏰐 􏰈􏰉􏰊􏰅􏰋􏰆􏰉􏰎 􏰘􏰉􏰆􏰉 in􏰗arian􏰅 -- 􏰎􏰇􏰛􏰉 􏰏􏰦􏰊􏰎􏰎 􏰍􏰐􏰗􏰊􏰆􏰍􏰊􏰐􏰅 􏰘􏰉􏰆􏰉 DATABASE􏰪􏰺2+ feat􏰋re imp+ -- 􏰎􏰇􏰛􏰉 􏰨􏰋􏰙􏰦􏰍􏰏 􏰈􏰉􏰊􏰅􏰋􏰆􏰉􏰎 􏰘􏰉􏰆􏰉 feat􏰋re -- 􏰳 NONE 􏰵 -- 􏰎􏰇􏰛􏰉 􏰍􏰛􏰨􏰦􏰉􏰛􏰉􏰐􏰅􏰊􏰅􏰍􏰇􏰐 􏰈􏰉􏰊􏰅􏰋􏰆􏰉􏰎 􏰘􏰉􏰆􏰉 in􏰗arian􏰅 -- 􏰎􏰇􏰛􏰉 􏰏􏰦􏰊􏰎􏰎 􏰍􏰐􏰗􏰊􏰆􏰍􏰊􏰐􏰅 􏰘􏰉􏰆􏰉 23 of 26 + ARRAYED􏰪LIST[PERSON] * LIST 􏰑PERSON􏰖 ++ ARRAYED􏰪LIST 􏰑PERSON􏰖 LINKED􏰪LIST 􏰑PERSON􏰖 Class Relations: Client-Supplier (3.2.1) We may focus on the PERSON supplier class, which may not help judge which design is better. DA􏰕ABA􏰜E􏰪􏰺1+ feat􏰋re im􏰨+: A􏰝􏰝A􏰯ED􏰪􏰮􏰞􏰜􏰕􏰑...􏰖 -- 􏰎􏰇􏰛􏰉 􏰨􏰋􏰙􏰦􏰍􏰏 􏰈􏰉􏰊􏰅􏰋􏰆􏰉􏰎 􏰘􏰉􏰆􏰉 feat􏰋re -- 􏰳 NONE 􏰵 -- 􏰎􏰇􏰛􏰉 􏰍􏰛􏰨􏰦􏰉􏰛􏰉􏰐􏰅􏰊􏰅􏰍􏰇􏰐 􏰈􏰉􏰊􏰅􏰋􏰆􏰉􏰎 􏰘􏰉􏰆􏰉 in􏰗arian􏰅 -- 􏰎􏰇􏰛􏰉 􏰏􏰦􏰊􏰎􏰎 􏰍􏰐􏰗􏰊􏰆􏰍􏰊􏰐􏰅 􏰘􏰉􏰆􏰉 DA􏰕ABA􏰜E􏰪􏰺2+ feat􏰋re imp+: 􏰮􏰞􏰜􏰕􏰑...􏰖 -- 􏰎􏰇􏰛􏰉 􏰨􏰋􏰙􏰦􏰍􏰏 􏰈􏰉􏰊􏰅􏰋􏰆􏰉􏰎 􏰘􏰉􏰆􏰉 feat􏰋re -- 􏰳 NONE 􏰵 -- 􏰎􏰇􏰛􏰉 􏰍􏰛􏰨􏰦􏰉􏰛􏰉􏰐􏰅􏰊􏰅􏰍􏰇􏰐 􏰈􏰉􏰊􏰅􏰋􏰆􏰉􏰎 􏰘􏰉􏰆􏰉 in􏰗arian􏰅 -- 􏰎􏰇􏰛􏰉 􏰏􏰦􏰊􏰎􏰎 􏰍􏰐􏰗􏰊􏰆􏰍􏰊􏰐􏰅 􏰘􏰉􏰆􏰉 + PERSON + PERSON 22 of 26 Clusters: Grouping Classes Use clusters to group classes into logical units. 􏰛􏰇􏰧􏰉􏰦 DA􏰕ABA􏰜E􏰑G􏰖* DA􏰕ABA􏰜E􏰪􏰺1􏰑G􏰖+ DATABASE􏰑G􏰖+ 􏰈􏰉􏰊􏰅􏰋􏰆􏰉 -- C􏰇􏰛􏰛􏰊􏰐􏰧􏰎 􏰊􏰧􏰧􏰪􏰍􏰅􏰉􏰛++ (􏰫: G) 􏰅􏰉􏰎􏰅􏰎 􏰧􏰙 DA􏰕ABA􏰜E􏰪􏰕E􏰜􏰕􏰜+ * 􏰮I􏰜􏰕􏰑G􏰖 ba􏰎􏰉-􏰦􏰍b􏰆a􏰆􏰷 -- I􏰐􏰎􏰉􏰆􏰅 􏰐􏰉􏰡 􏰍􏰅􏰉􏰛 􏰻􏰫􏰻 􏰍􏰐􏰅􏰇 􏰅􏰘􏰉 􏰆􏰍􏰫􏰘􏰅 􏰎􏰦􏰇􏰅 􏰇􏰈 􏰻􏰧􏰊􏰅􏰊􏰻. im􏰨 􏰈􏰉􏰊􏰅􏰋􏰆􏰉 -- 􏰽􏰋􏰉􏰆􏰍􏰉􏰎 􏰏􏰇􏰋􏰐􏰅+: IN􏰕EGE􏰝 -- 􏰔􏰋􏰛􏰙􏰉􏰆 􏰇􏰈 􏰍􏰅􏰉􏰛􏰎 􏰎􏰅􏰇􏰆􏰉􏰧 􏰍􏰐 􏰧􏰊􏰅􏰊􏰙􏰊􏰎􏰉 􏰉􏰣􏰍􏰎􏰅􏰎++ (􏰫: G): B􏰒􏰒LEAN -- 􏰹􏰉􏰆􏰈􏰇􏰆􏰛 􏰊 􏰙􏰍􏰐􏰊􏰆􏰷 􏰎􏰉􏰊􏰆􏰏􏰘 􏰇􏰐 􏰻􏰧􏰊􏰅􏰊􏰻 􏰊􏰆􏰆􏰊􏰷. 􏰍􏰐􏰗􏰊􏰆􏰍􏰊􏰐􏰅 􏰎􏰇􏰆􏰅􏰉􏰧_􏰧a􏰅a: ∀􏰍 : 1 􏰩 􏰍 < 􏰏􏰇􏰋􏰐􏰅 : 􏰧􏰊􏰅􏰊􏰑􏰍􏰖 < 􏰧􏰊􏰅􏰊􏰑􏰍 + 1􏰖 ++ A􏰝􏰝A􏰯ED􏰪􏰮I􏰜􏰕􏰑G􏰖 􏰮I􏰔􏰰ED􏰪􏰮I􏰜􏰕􏰑G􏰖 24 of 26 Beyond this lecture ● Your Lab0 introductory tutorial series contains the following classes: ○ BIRTHDAY ○ BIRTHDAY BOOK ○ TEST BIRTHDAY ○ TEST BIRTHDAY BOOK ○ TEST LIBRARY ○ BAD BIRTHDAY VIOLATING DAY SET ○ BIRTHDAY BOOK VIOLATING NAME ADDED TO END Draw a design diagram showing the architectural relations among the above classes. 25 of 26 Index (2) Features: Deferred, Effective, Redefined (2) Features: Deferred, Effective, Redefined (3) Classes: Deferred vs. Effective (2.1) Classes: Deferred vs. Effective (2.2) Class Relations: Inheritance (1) Class Relations: Inheritance (2) Class Relations: Client-Supplier (1) Class Relations: Client-Supplier (2.1) Class Relations: Client-Supplier (2.2.1) Class Relations: Client-Supplier (2.2.2) Class Relations: Client-Supplier (3.1) 27 of 26 Index (1) Learning Objectives Why a Design Diagram? Classes: Detailed View vs. Compact View (1) Classes: Detailed View vs. Compact View (2) Contracts: Mathematical vs. Programming Classes: Generic vs. Non-Generic Deferred vs. Effective Classes: Deferred vs. Effective Features: Deferred, Effective, Redefined (1) 26 of 26 Index (3) Class Relations: Client-Supplier (3.2.1) Class Relations: Client-Supplier (3.2.2) Clusters: Grouping Classes Beyond this lecture 28 of 26