Modularity (1): Childhood Activity Modularity Abstract Data Types - PowerPoint PPT Presentation

Modularity (1): Childhood Activity Modularity Abstract Data Types (ADTs) EECS3311 A & E: Software Design Fall 2020 C HEN -W EI W ANG (I NTERFACE ) S PECIFICATION (A SSEMBLY ) A RCHITECTURE Sources: https://commons.wikimedia.org and https://www.wish.com 3 of 16 Learning Objectives Modularity (2): Daily Construction Upon completing this lecture, you are expected to understand: 1. Criterion of Modularity , Modular Design 2. Abstract Data Types ( ADTs ) (I NTERFACE ) S PECIFICATION (A SSEMBLY ) A RCHITECTURE Source: https://usermanual.wiki/ 2 of 16 4 of 16

Modularity (3): Computer Architecture Modularity (5): Software Design Software systems are composed of well-specified classes . Motherboards are built from functioning units (e.g., CPUs ). I�ERA�ION�C�RSOR �G�* sorted­collections ne�_c�����* * ����*: G ITERABLE [G] �����* SOR�ED�AD� �K, ��* �����*: BOOLEAN fea���e ­­ ����� �����: SEQ �KV�PAIR�K,V�� sorted­maps fea���e ­­ �������� ������ (������: TUPLE ����: K; �����: V�) student­design �eq�i�e ¬ ��� (������.���) SOR�ED�MAP�AD� �K, ��* ������ (�����: K) fea���e ­­ ����� ne�_c�����+ + �eq�i�e ��� (�����) �����: FUN�K, V� SORTED_MAP_ �����������: ARRAY �K� CURSOR [K, V] fea���e ­­ ������� ���� alia� "��" (�����: K): V fea���e ­­ �������� �eq�i�e ��� (�����) ������ (���: K; ���: V) �eq�i�e ¬ ��� (���) ��������: ARRAY�KV�PAIR�K,V�� * im�lemen�a�i�n SORTED_MAP_ ������ (���: K) DESIGN [K, V] in�a�ian� �eq�i�e ��� (���) ∀ � ∈ �1, �����.�����): ��������.��� < �������+1�.��� fea���e ­­ ������� ����(���:K): V ∀ � ∈ �1, �����.������: ��� (���: K): BOOLEAN ����������� � �������� + + + in�a�ian� SORTED_RBT_ SORTED_BST_ SORTED_LINEAR_ ∀ � ∈ �1, �����.�����): MAP [K, V] MAP [K, V] MAP [K, V] �������������� < �������������+1� �����������.����� = �����.����� ∀ � ∈ �����.������ : � ∈ ����������� im�lemen�a�i�n + + SORTED_ SORTED_ LINEAR [K, V] TREE [K, V] (I NTERFACE ) S PECIFICATION (A SSEMBLY ) A RCHITECTURE im�lemen�a�i�n + + SORTED_ SORTED_ + BST [K, V] RBT [K, V] SORTED_MODEL_MAP [K, V] im�lemen�a�i�n Sources: www.embeddedlinux.org.cn and https://en.wikipedia.org 5 of 16 7 of 16 Modularity (4): System Development Design Principle: Modularity ● Modularity refers to a sound quality of your design: Safety-critical systems (e.g., nuclear shutdown systems ) are 1. Divide a given complex problem into inter-related sub-problems via a logical/justifiable functional decomposition. built from function blocks . e.g., In designing a game, solve sub-problems of: 1) rules of the (* DECLARATION *) +---------+ game; 2) actor characterizations; and 3) presentation. (* Function block body in FBD language *) | LIMITS_ | HIGH_ALARM +------------+ | ALARM | 2. Specify each sub-solution as a module with a clear interface : | HYSTERESIS | REAL--|H QH|--BOOL X------------------------+--|XIN1 Q|--+----------QH inputs, outputs, and input-output relations . REAL--|X Q|--BOOL +---+ w2| | | | H----------------| - |------|XIN2 | | REAL--|L QL|--BOOL ● The U NIX principle: Each command does one thing and does it well. +---| | | | | | REAL--|EPS | | +---+ | | | | +--------------|EPS | | +-----+ ● In objected-oriented design (OOD), each class serves as a module. +---------+ +---+w1| | +------------+ +--| >=1 | X EPS --| / |--| | | |--Q 3. Conquer original problem by assembling sub-solutions . FUNCTION_BLOCK LIMITS_ALARM VAR_INPUT QH=1(TRUE) 2.0 --| | | | LOW_ALARM +--| | H H : REAL; (* High limit *) +---+ | | +------------+ | +-----+ ● In OOD, classes are assembled via client-supplier relations H-(EPS/2) NC(No change) X : REAL; (* Variable value *) | +---+ w3| | HYSTERESIS | | L : REAL; (* Lower limit *) H-EPS L ---------------| + |------|XIN1 Q|--+-----------QL QH=0(FASLE) (aggregations or compositions) or inheritance relations. EPS : REAL; (* Hysteresis *) | | | | | | END_VAR QL=0(FALSE) +---| | +--|XIN2 | VAR_OUTPUT L+EPS ● A modular design satisfies the criterion of modularity and is: | +---+ | | QH : BOOL; (* High flag *) L+(EPS/2) NC(No change) +--------------|EPS | Q : BOOL; (* Alarm output *) L QL : BOOL; (* Low flag *) +------------+ QL=1(TRUE) ○ Maintainable : fix issues by changing the relevant modules only. END_VAR END_FUNCTION_BLOCK TIME ○ Extensible : introduce new functionalities by adding new modules. (I NTERFACE ) S PECIFICATION (A SSEMBLY ) A RCHITECTURE ○ Reusable : a module may be used in different compositions ● Opposite of modularity: A superman module doing everything. Sources: https://plcopen.org/iec-61131-3 6 of 16 8 of 16

Abstract Data Types (ADTs) Why Java Interfaces Unacceptable ADTs (1) ● Given a problem, decompose its solution into modules . ● Each module implements an abstract data type (ADT) : ○ filters out irrelevant details ○ contains a list of declared data and well-specified operations ADT Interface request Data add() Structure remove() result find() ● Supplier’s Obligations: ○ Implement all operations It is useful to have: ○ Choose the “right” data structure (DS) ● Client’s Benefits: ● A generic collection class where the homogeneous type of ○ Correct output elements are parameterized as E . ○ Efficient performance ● A reasonably intuitive overview of the ADT. ● The internal details of an implemented ADT should be hidden . Java 8 List API 9 of 16 11 of 16 Building ADTs for Reusability Why Java Interfaces Unacceptable ADTs (2) Methods described in a natural language can be ambiguous : ● ADTs are reusable software components e.g., Stacks, Queues, Lists, Dictionaries, Trees, Graphs ● An ADT, once thoroughly tested, can be reused by: ○ Suppliers of other ADTs ○ Clients of Applications ● As a supplier, you are obliged to: ○ Implement given ADTs using other ADTs (e.g., arrays, linked lists, hash tables, etc.) ○ Design algorithms that make use of standard ADTs ● For each ADT that you build, you ought to be clear about: ○ The list of supported operations (i.e., interface ) ● The interface of an ADT should be more than method signatures and natural language descriptions: ● How are clients supposed to use these methods? [ preconditions ] ● What are the services provided by suppliers? [ postconditions ] ○ Time (and sometimes space) complexity of each operation 10 of 16 12 of 16

Why Eiffel Contract Views are ADTs (1) Beyond this lecture... class interface ARRAYED_CONTAINER 1. Q. Can you think of more real-life examples of leveraging the feature -- Commands assign_at ( i : INTEGER ; s : STRING ) power of modularity ? -- Change the value at position ’i’ to ’s’. require 2. Visit the Java API page: valid_index : 1 <= i and i <= count https://docs.oracle.com/javase/8/docs/api ensure size_unchanged : Visit collection classes which you used in EECS2030 (e.g., imp . count = ( old imp . twin ). count ArrayList , HashMap ) and EECS2011. item_assigned : imp [ i ] ∼ s Q. Can you identify/justify some example methods which others_unchanged : across illustrate that these Java collection classes are not true ADTs 1 |..| imp . count as j (i.e., ones with well-specified interfaces)? all j . item /= i implies imp [ j . item ] ∼ ( old imp . twin ) [ j . item ] 3. Constrast with the corresponding library classes and features in end EiffelStudio (e.g., ARRAYED LIST , HASH TABLE ). count : INTEGER invariant Q. Are these Eiffel features better specified w.r.t. consistency : imp . count = count obligations/benefits of clients/suppliers? end -- class ARRAYED_CONTAINER 13 of 16 15 of 16 Why Eiffel Contract Views are ADTs (2) Index (1) Even better, the direct correspondence from Eiffel operators to Learning Objectives logic allow us to present a precise behavioural view. Modularity (1): Childhood Activity Modularity (2): Daily Construction Modularity (3): Computer Architecture Modularity (4): System Development Modularity (5): Software Design Design Principle: Modularity Abstract Data Types (ADTs) Building ADTs for Reusability Why Java Interfaces Unacceptable ADTs (1) Why Java Interfaces Unacceptable ADTs (2) 14 of 16 16 of 16

Index (2) Why Eiffel Contract Views are ADTs (1) Why Eiffel Contract Views are ADTs (2) Beyond this lecture... 17 of 16