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
featre — A, B,
— A, B,
featre — NONE —
inarian
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:
HAHABEG, H ABE1G, EGE ABE2E, EGE
○ If necessary, present a generic class in the detailed form:
DATABASEG+
feature
-- feature -- NONE
-- : ARRAYG inarian
--
MDB1STRING+
feature
-- feature -- NONE
-- : ARRAYSTRING inarian
--
MDB2PERSON+
feature
-- feature -- NONE
-- : ARRAYPERON inarian
--
● 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: AAEDCONAINE+
-- Q c+: INEGER
-- N a
-- Cad
a_a+ (: INEGER; : RING)
-- Ca a a '' ''.
a_: 1 c
_a: .c = ( .).c
_a: []
_a: ∀ : 1 .c : ⇒[] ( .) []
-- NONE +: ARRA[RING]
-- Ia a aa-a inarian
: .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:
LIG*
LILIPERON*
DAABAEG*
13 of 26
LINKEDLIG+
LINKEDLIINEGER+
DAABAE1G+
ARRAEDLIG+
ARRAEDLIG+
DAABAE2G+
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]*
featre
-- featre -- NONE
--
inarian
--
++
MY LIST IMPONE[G+ MY LIST IMPTWO[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: DAABAE* DAABAE1+ DAABAE2+
E -- I : AAG
-- C * (: G)
-- A .
_eiig_ie: ()
ie_iceeed: = + 1 ie_added: ()
-- +: IEGE
-- N
cec_el: = .
* (: G): BLEA
-- D ?
cec_el: = (∃ : 1 : )
E -- I : AAG
-- C + (: G)
-- A . --
+: IEGE
-- N
+ (: G): BLEA
-- .
E -- I : AAG
-- C ++ (: G)
-- I . --
+: IEGE
-- N
++ (: G): BLEA
-- .
ed_daa: ∀ : 1 < : < + 1
14 of 26
Class Relations: Inheritance (2)
More examples (emphasizing different aspects of DATABASE): Inheritance Hierarchy Features being (Re-)Implemented
DAABAE*
DAABAE1+
DAABAE2+
DAABAEG* E --
: AAG
-- C * (: G)
-- A .
_eiig_ie: ()
ie_iceeed: = + 1 ie_added: ()
-- +: IEGE
--
cec_el: = .
* (: G): BLEA
-- D ?
cec_el: = (∃ : 1 : )
DAABAE1G+
DAABAE2G+ E --
: AAG
-- C ++ (: G)
-- .
-- +: IEGE
--
++ (: G): BLEA
-- .
16 of 26
ed_daa: ∀ : 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.
DAABAE+
+ (: ING)
-- Add a `` daaba.
...
...
+ (: ING): BOOLEAN -- D a `` ?
...
...
inariant
...
19 of 26
data+: ARRA...
n, nn
data: ARRAY[...]
+ G
E+
+ (: AAING; : ING): BOOLEAN
-- D a `` aa `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
AABA+
+ (: ING)
-- Add a `` daaba.
...
...
+ (: ING): BOOLEAN -- D a `` ?
...
...
inarian
...
+
n, nn
+ AA
+
+ 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.
DATABASE1+
featre imp+ --
featre -- NONE
--
inarian
--
DATABASE2+
featre imp+ --
featre -- NONE
--
inarian
--
23 of 26
+ ARRAYEDLIST[PERSON]
*
LIST PERSON
++ ARRAYEDLIST PERSON LINKEDLIST 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.
DAABAE1+
featre im+: AAED... --
featre -- NONE
--
inarian
--
DAABAE2+
featre imp+: ... --
featre -- NONE
--
inarian
--
+ PERSON
+ PERSON
22 of 26
Clusters: Grouping Classes
Use clusters to group classes into logical units.
DAABAEG*
DAABAE1G+
DATABASEG+
-- C ++ (: G)
DAABAEE+
* IG
ba-ba
-- I . im
-- +: INEGE
--
++ (: G): BLEAN
-- .
_aa: ∀ : 1 < : < + 1
++ AAEDIG IEDIG
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