Detail midlevel part Design MidLevel OO Design Designing

Detail (mid-level part) Design: Mid-Level OO Design – Designing Classes • Detailed Design starts with Software Architecture Design (SAD) and fill in the details of the architectural components - - - may cause re-work on SAD, too. • There is no “fixed” boundary between SAD and Detailed Design - - - it is not strictly sequential & we may iterate back and forth. • Detailed Design has 2 levels: – Mid-level (this lecture set) – Low-level (later lecture) • Detailed Design may be: – Static: non-execution oriented (mostly this lecture set) – Dynamic: execution oriented (next lecture set)

Detailed Design Process Analyzed SRS Analyze SRS and SAD Swft Engr. Design SAD SRS Design Analysis Evaluate Detailed Design Alternatives Architectural Design Detail Design Generate/Improve Detailed Design Alternatives Design Doc. Select Detailed Resolution [else ] [selected ] Finalize Detailed Design Doc

Relative “Levels” of Mid-Level to Detailed-Level Design 1. Conceptual Level : – the class or subcomponent should express the “responsibilities” and “attributes” of the subcomponents or Classes 2. Specification Level: – The subcomponent’s or Class’ precise “interface” and associations between/among classes or subcomponents are specified 3. Implementation Level: – The concrete class or subcomponent that “implements” the interface, with instance variables and algorithms for the code, are described

Mid-Level Detailed Design The unit of design is at the Compiled • – – – • Unit or at a Class level: Properties Responsibilities Relationships The mid-level design specifications include (De. SCRIPTR): 1. 2. 3. 4. 5. 6. 7. 8. Decomposed mid-level components States of these components Collaboration among these mid-level components Responsibilities of each of these mid-level components to perform some task or maintain data Interfaces that these mid-level components use to communicate with each other Properties (such as security, reliability, performance) of these components must be specified. Transition of states and state behavior of these components are described Relationships (inheritance, aggregation, composition, etc. ) among the components

Low-Level Detailed Design • In contrast to mid-level, low level detailed design fills in the details for later programming purpose (PAID): 1. 2. 3. 4. Packaging of the code into compilation unit and libraries is decided Algorithms are described in detail steps Implementation issues such as visibility and accessibility of entities and low level relationships among entities are described Data structures and data types are specified

Sample: Detailed Design Document Content 1. Mid-Level Design Models (in the form of Class diagrams, 2. Low-Level Design Models (specific algorithms, data 3. Mapping between Models (showing how the models are related) 4. Description of Design Rationale (describing the design decisions made and factors that contributed to the decision) very important 5. Glossary of terms and acronyms used sequence diagrams, state transition diagrams, etc. ) structures, implementation guidelines for non-functional attributes such as security or performance, packaging) average importance

Static Descriptions (Design) (based on text book & thus OO Biased ) Rest of this lesson lecture notes will focus on the following: • Associations Among Classes – – Generalization and inheritance (“is a” relationship) Interfaces of classes Aggregation (“part-whole” relationship) & Composition Adornments for more complex association • Classes – More properties about attributes and operations may be specified: • With { } to indicate constraint • Visibility and Accessibility indicator • Class or Instance variables

Class Generalization/Inheritance & Association • Generalization is a “parent-child” or “sub-typing” relation between classes ---- close to the notion of abstraction – e. g. dog “is a” animal • Association represents a more general relationships between instances of classes – A person “works” for a company; company “has” a number of buildings fish person whale salmon Generalization 1 -- * Works for Association 0. . 2 company

Multiple Inheritance salmon fish mammal size: int breathe( ) move( ) whale dog Consider: Whale really “is a” fish at the same time “is a” mammal? Which “move ( )” or breathe( ) operation should be inherited ?

Abstract Class for mid-level design • In design we May Not fill in all the details of a design. – Abstract class is an example of such a situation. – An Abstract Class is a class that can not be instantiated because it contains a method or operation without the body. • It is useful as a parent-class which is inherited by some childclass that has “implemented” the method that has no body. <<abstract>> animal If we do not use stereotype descriptors, then we must italicize to show abstract class weight: int origin: string move ( ) {abstract} fish dog Each of the sub-classes: - fish - dog - bird will have a different move( ) operation that needs to be “implemented” differently bird We use abstract class as a design for the purpose of enforcing a certain set of common attributes and operations that must be inherited by all descendants ( You may think of this as a “restricted or controlled” polymorphism )

Interfaces for mid-level design • Interfaces are important in design because it shows the relationship of dependencies (of features - attributes or/and operations) • Earlier we have discussed the provided and the required interfaces, along with the “ball” and the “cup” to indicate the provider of the feature versus the dependent of that feature. • Here we show another notational approach temperature gauge Provided interface <<interface>> temperature temp: object Required interface thermostat Update. Temp (temp: object) Get. Temp ( ): object thermostat

Further notes on Interface • In Java programming, “Interface” contains: – constants and – abstract methods • abstract method is just a signature that has no implementation • Interfaces in Java programming provides a certain amount of polymorphism through different classes that “implement” the interface • Also note that we can use interface to perform “information encapsulation” by making the data only accessible through the interface method.

More “Specifications” for Mid-Level design • More properties may be “specified” for the attributes and operations using { }, constraint Department Dep. Name: string {constant} Person: employee: Memlist: employee[*] {ordered} add. Empl (person: employee) del. Empl (person: employee) {synchro} Department name is a string constant. Memlist is an ordered list. del. Empl is an operation that must be synchronized. Recall from (p. 202 -203 of your textbook): Attribute format name : type [multiplicity] = initial value Operation format - name (parameter list) : return-type-list

“Visibility” Characterization for Mid-Level Design • Visibility or accessibility constraints on attributes and operations should be thought of at mid-level design: visible hidden – Public (+): visible and accessible anywhere by everyone – Package (~): visible and accessible within the package where the class appears – Protected (#): visible and accessible within the class and all its sub-classes – Private (-): visible and accessible only within the class Department + Name: string {constant} : + Memlist: Employee[*] (ordered} # address: string Also, go back to the interface diagram and see if you would make the attribute, temp, to have a “private” designation --why ?

Class (global) and Instance (local) notions for mid-level -design • During mid-level design, we need to specify which attribute and/or operation should be “global” in nature versus “local” in nature. – Class level : one copy and sharable among all instances of the class. (sometimes called “static” variable and is underlined) • A constant such as Pi may be a class variable that is shared by all objects figure +pi : double {constant} – Instance level: a separate copy for each instance of the class (or object) and the value of the copy is specific to only that instance. • An employee. Name may be an instance variable that is read in by different objects and varies depends on which employee record is read by which object.

Differentiating “Part-Whole” Relationship Concepts following has always been a tough distinction to remember: • Aggregation is a “part-whole” association. • Composition is a “special kind” of aggregation where the part may only belong to one whole at any time. Replenish-list Sold-item list subdivision house 1…* item 1…* kitchen An item may belong to the replenish-list and may also be on the sold-item list. Is the aggregation symbol A kitchen belongs to only one house, which in-turn sits in only one subdivision. is the composition symbol.

Transitivity Property • Note that some relationship may look like an aggregation, but not. Aggregation should be transitive. 1. Person Z is biologically-related to father y; father y is biologically related to family x. The person Z is biologically related to the family x. (this is a transitive relationship --- thus an aggregation) 2. Joe is a member of a church y; church y is a member of entities that don’t pay taxes. Is Joe a member of entities that don’t pay taxes? --- but Joe may pay tax! (be careful with is “a member of” versus “possess the characteristics” of )

Complex Association • Sometimes association itself may be complex and needs a class, which has attributes and operations pertinent to the association. – We can use an Association Class to provide the information pertinent to the association that does not belong to either of the associated objects. << sold to >> Items customer Sales date Item-list sales-person Further describes the sold-to association

More adornments for association • Qualifiers : one or more association attributes, which together with an instance of the qualified class, picks out the instances of the other class that participate in the association. • Navigability: indicates if an instance of a class can access (one way or two ways) an instance of the associated class. • Visibility: indicates the attribute that is used for accessing (association) between the two instances of classes is public, private or protected.

Association Qualification adornment Univ. Directories student name student id# 0. . * 1. Note that given a university directory, with the qualifier of student name and id#, there is either such a student or none 2 0. . 1 Student Given a student there may be no entry in any of the university directories (error) or one or more entries in different university directories

Association Navigation &Visibility adornments Navigation of student accesses classes, but not vise versa Student Class X 0. . * Navigation of Class and Building are bi-directional and are done through accessing the public attribute 1 + class_id and building_id are publicly visible + building_id Building

“Coming Up with” or Drafting the Mid-Level Design • This discussion is primarily OO-based; thus the aim is to come up with mid-level design of classes – Creational technique : • Decomposition/Composition based on functionality, “quality” (non-functional) attributes, or both (just as we did for High Level Design) – Transformational technique: • Converting the conceptual (problem) model to a draft design model (much as what was done with High Level Design) • Requires a good SRS and SAD or • Transforming a previously completed, similar design For experienced people, they usually have some previous, similar design in their brain and would draw upon that first--- and then create more

Creational Technique 1. 2. Generate a Design Story (based on what you think are the most important aspects of the solution); list the key “themes” in the story. Use themes and “brainstorm. ” For each theme identify and list: Generating • Entities in charge or involved in theme Classes from • Things that interact with the solution part of theme Themes • • 3. From the list in step 2, generate “candidate” classes. • • 4. List their names List their responsibilities Evaluate the list of classes: • Discard those that seem to be unclear in name or responsibilities • Rework those classes that have overlapping responsibilities • Discard those that seem to be “out of scope” 5. Draft an initial Class diagram showing • • 6. Things whose data needs to be stored Any structure or collections of entities Classes, each with attributes and operations Associations among classes Developing a list of classes and the class diagram Review and Check the Class Diagram: improve the • Check each class for missing/inaccurate attributes and operations class • Combine common attributes and operations into a super-class, if diagram necessary • Look for “required’ and “provided” components (using design patterns)

Transformational Technique 1. 2. 3. 4. 5. 6. 7. Start with the conceptual model (requirements and high level design) and convert the actors in the conceptual model to interface classes. Add data collection classes for all those actors whose data needs to be recorded Add a start-up class to start the execution of the solution. Convert controllers and coordinators in the conceptual model into classes and add any that needs to be included as control and coordination classes. Data types with complex structure in the conceptual model needs to be converted to classes Decide on whether container classes (abstract data structure) are needed, include them if necessary Add Associations and interfaces; draft the class diagram

Some Static Modeling Heuristics for mid-level design 1. Responsibility driven decomposition 2. Inheritance 3. Delegation

Responsibilities Driven Decomposition • Responsibility (functionality) is an obligation to: – Perform a task (operational responsibility) – Maintain some data and non-functional information (data responsibility) • Responsibility driven decomposition – Generating lower level operational responsibility components based on decomposing the high-level operational responsibilities – Generating lower level data responsibility components based on decomposing the high-level data responsibilities. • Responsibility and design principles (cohesion and coupling): – Assign a module (class) with at most one operational responsibility and one data responsibility - - - cohesion ----practical ? – Assign complementary data and operational responsibilities together- - cohesion – Make sure module responsibilities do not overlap - - - cohesion and coupling – Do not place extra operational and data elements into a module - - cohesion and coupling – Make sure that all needed operational and data elements are included in the module to fulfill the responsibilities - - - cohesion and coupling

Starting a Design (used for discussion of “inheritance” and “delegation” --- later) Consider designing a component dealing with a bank account. A bank account handles the deposit and withdrawal of that account. Each bank account is owned by one to three people. Information about a bank account such as owner, open date, account type must be kept and maintained. Account amt : real total_amt: real act_num: int Deposit (amt : real, act: int ) Wdraw (amt : real, act : int) Note: What should we do with account information such as account type or owner ?

Capture the Ownership Information & Relationship Owner_Info Account amt : real total_amt: real act_num: int 1. . 3 * addr : string Tel : int ss_num: int B-date: date Act_num : int . Deposit (amt : real, act: int ) Wdraw (amt : real, act ; int) Account_info setaddr ( ) getaddr ( ) . .

Discussion on Cohesion and Coupling Consider designing a component dealing with bank account and account information Account amt : real total_amt: real a_num: int deposit(amt : real, a_num: int ) wdraw (amt : real, a_num ; int) Account_Info 0. . 1 owner: string 1 co-owner: string act_type: integer act_st_date: date act_num: int get. Owner (act_num: int) string set. Owner (act_num: int, owner: string) . . Should these be combined as one Class or left separately? (cohesion and coupling trade-off ? )

More Discussion on Cohesion and Coupling (cont. ) How should these Classes be combined, if at all? Account amt : real total_amt: real a_num: int deposit(amt : real, a_num: int ) wdraw (amt : real, a_num ; int) Account_Info owner_name: string act_type: int act_st_date: date act_num: int Owner_Info name: string addr : string tel : int ss_num: int b-date: date get. Owner (act_num: int) string. set. Owner (act_num: int, owner: string) setaddr ( ). . . getaddr ( ) Should these be somehow combined or left separately? (cohesion and coupling trade-off ? – and db performance ? ) . .

Inheritance • Remember: – Inheritance is a generalization relationship between a super-class and its sub-classes. – Inheritance provides a mechanism for re-use in mid-level designs. 1. Combine common attributes and operations in similar classes into a super-class 2. Use inheritance only when there is a generalization relationship between the super-class and its sub-classes.

Generalized Account_Info (from earlier example) for Inheritance? • Instead of act_type attribute in the Account_Info Class to differentiate the different accounts, should we have designed a “generalized” Account_Info class and have each account type inherit from the generalized class: – Personal checking account with all kinds of rules such as free checking for 6 months, overdraft fee, etc. – Personal money market account with no minimum deposit, but gives only regular interest – Personal money market account with minimum of $50, 000 deposit gets regular interest plus. 25% more. – Small Business account. .

Delegation • Delegation is a mechanism to decompose the responsibilities and assign some of the responsibilities to different classes. • This allows classes to re-use a class that has been given a set of responsibilities that is needed by other classes. So ---- based on delegation, should we keep Account and Account_Info separately ?