Session 4 Design Class Diagram Deployment Diagram Component

Session 4 § Design § Class Diagram § Deployment Diagram § Component Diagram

Object Oriented Design Process Design Classes, Methods, Attributes, and associations Apply Design Axioms Refine UML Class Design View Access Layer and Prototype User Satisfaction and usability tests based on use cases Methods, Continue Testing 2

Associations in Citi. Bank Classes ATMMachine #address #state Bank Transaction Bank client #firstname #last. Name #card. Number #pin. Number #account Account Has 1, 2 1 Checking Account #savings 1 #number #balance #bank. Client #transaction 1 * Account Transaction 1 1 #trans. ID #transdate #trans. Time #trans. Type #amount #post. Balance Saving Account #checking Savings checking 3

Adding Attributes and Methods • Attribute – Analyse use case, sequence and colaboration – What info class should have – Class Bank. Client • • • first. Name last. Name pin. Number Card. Number Account 4

Adding Attributes and Methods • Methods (Object responsibility) – Workhorses for OOS – Each piece of data is surrounded by rich set of methods – Responsible for managing attributes value – Class Account • • • +Depositchecking() +withdraw() +Checking transactionhistory() 5

OO Design Axioms • An Axiom is fundamental truth • A theorem is a proposition that may not be self -evident but can be proven from accepted axioms • A Corollary is a proposition that follows from an axiom or another proposition that has been proven. 6

Suh’s Design Axioms • Axiom 1 : The Independence Axiom – Maintain the independence of components – While satisfying a requirement a component should not affect other requirement. • Axiom 2 : The information Axiom – Minimize the information content of the design – The best Theory explains the known facts with a minimum amount of complexity and maximum simplicity and straightforwardness 7

Corollaries • From two Axioms many corollaries be derived • More useful into making specific design decision • Can be applied more easily than original axioms • They can be called design rules 8

Corollaries Corollary 4. Corollary 1. Axiom 1. Corollary 2. Axiom 2. Corollary 5. Corollary 3. Corollary 6. The origin of Corollary 1, 2 and 3 are from both axioms whereas Corollary 4 is from Axiom 1 and Corollaries 5 and 6 are from Axiom 2. 9

Corollary 1 • Uncoupled design with less information content – Minimal amount of essential information need to be passed between objects. – Coupling : is a measure of strength of association established by a connection from one object to another 10

Coupling • Inteaction Coupling – – Involves the amount and complexity of information transfrerred It is desirable to have less interaction Message should be simple and infrequent Object connected to many very complex messages are tightly coupled, means any change in one will have ripple effect in other • Inheritance Coupling – Between Super Class and Sub-Class( interms of attributes and methods) – Unlike interaction Coupling, inheritance coupling is desirable. 11

Cohesion • Interactions within a single object or component • Highly cohesive components lower coupling • A method that carries multiple function is undesirable 12

Corollary 2 • Single purpose • Each class must have a single purpose • Should be able to document in a sentence or two • Keep it Simple : to be more precise – Each method should provide only one service – Each method should be of moderate size no more than a page 13

Corollary 3 • Large number of simpler classes, Reusability • The smaller are our classes, more is the chance of its reuse. • Large and complex classes are too specialised to be reused 14

Corollary 4 • Strong Mapping • As model progress from analysis to design to implementation more details are added but it remain essentially the same • A strong mapping links classes identified during Analysis to the one in Design. 15

Corollary 5 • Standardization • Platform independent 16

Corollary 6. • Designing with inheritance • Use single and multiple inheritance 17

Designing Classes : The process • Apply design axioms to design classes, their attributes, methods and associations, structures and protocols. – Refine and complete the static UML class diagram by adding details to that diagram • Refine attributes • Design methods and protocols by utilizing a UML activity diagram to represent the methods diagram. • Refine the associations between classes. Use inheritance – Iterate and refine. 18

Class visibility • Implementation is hidden and is off limet for other objects • Public protocol define the functionality and external messages of an object • Private protocols defines the implementation of an object. • Avoid Encapsulation leakage 19

Designing Classes : Refining Attributes • In Analysis name of the attribute is sufficient However in design more details should be added • Attribute Types – Single value • Most Common, one value or state e. g. name, salary – Multiplicity or multivalue • Collection of many value at a time • Name of people who have called for Customer support. – Reference to another Object , or instance • Joint accounts implementation 20

Refining Attribute for Citibank Objects • Bank. Client Class – During OOA we identified • • Firstname Lastname pin. Number card. Number – To add more information in this phase#first. Name: String • • #lastname: String #pin. Number: String #card. Number: Account (instance connection) – (All the attribute has been given protected visibility) 21

Refining Attribute for Citibank Objects • Account Class – #number: float – #balance: float – #transaction: (association between account and transaction class) – #bank. Client: (association between Account and bank. Client Class) 22

Refining Attribute for Citibank Objects • ATMMachine class – #address : String – #state : String • Transaction Class – – – #trans. ID : String #transdate : Date #trans. Time : Time #trans. Type : String #amount : float #post. Balance : float 23

Designing Methods and Protocols • A class can provide several types of methods – – – – Constructor (Method that creates instances) Destructor (Method that destroys instances) Conversion (Converts one unit to another) Copy method ( The method that copies the content) Attrib Set (that sets the values of attributes) Attrib Get (that returns) I/O Methods (Provide or receive data from device) Domain Specific ( The method specific to the application) 24

UML Operation Presentation • visibility name: (parameter-list): return-typeexpression • Where visibility is – + Public – # Protected – - Private • name is the name of the operation • parameter list is the list of parameter separated by commas • return-type-expression: is a language independent specification of return method 25

Activity diagram for bankclient class Bank. Client: : +verify. Password(card. Number: String, a. PIN : String): a. Client : Bank. Cli a. Client = retrieve. Client (cardnumber, a. PIN) #retrieve. Client(card. Number: String, a. PIN : String): a. Client : Bank. Clien Nil PIN Valid PIN Not Valid Display “Incorrect PIN, Please try again” Provide Access to account 26

Complete UML Class Diagram ATMMachine #address : String #state : String Bank Transaction Bank client #firstname : String #last. Name : String #card. Number : String #pin. Number : String #account : Account Has 1 #number String 1, 2 #balance : String * #bank. Client : Bank. Client #transaction : Transaction 1 Checking Account #savings : Account 1 Account Transaction 1 #trans. ID : String #transdate : Date #trans. Time : Time #trans. Type : String #amount : float #post. Balance : float Saving Account #checking : Account Savings checking 1 27

Testing Scenarios • • • Execution of a program to find its fault. Find and remove bugs Time consuming Critical part of software success Over half the modules are often error free While there are many unappreciated gardens, the few remaining thickets get the users attention 28

Definitions • Testing : the process of executing a program with the intention of finding errors. • Verification : An attempt to find errors by executing a program in a test or simulated environment (correctness) • Validation : An attempt to find errors by executing a program in a real environment • Debugging : Diagnosing the precise nature of known error and then correcting it. (Debugging is a correction not a testing activity) 29

Testing methods : Stress Testing • Tests has to be designed to handle a specific load • Load is steadily increased • ST Continues continue these tests beyond the maximum design load of the system until the system fails • Relevant to distributed system 30

Regression Testing • New functions added and older modified • Regressive testing concerns the effects of newly introduced changes to all previously tested code • In large system these regression problems are common • Best way is to select few test cases and run them periodically (Bucket) 31

Performance Testing • For Real Time and embedded System • Designed to test run time performance of software • Identifies current bottlenecks • “At what point will my application malfunction fail or malfunction? ” 32

Scalability Testing • Increase number of concurrent user • Increase server hardware capability and load • Hardware software integration to make a system successful 33

Component Diagram • • Models the Imp. Physical aspect of the system Physical and replaceable part of system Are used to model thinks like exe, lib, tables. . Typically it’s the physical packaging of otherwise logical elements • UML Representation Kernel 32. dll 34

Component and Classes • • Both have names Both realize a set of interfaces Both have instances , Associations However Classes represent logical abstractions; Component represent physical things that live in this world • If thing you model reside on a node, use component; otherwise Class 35

Component • • • Provide interfaces Are replaceable Are physical Is a part of system Type of component – Deployment component (DLL and exe – Work Product (residue of development, source code from which the component deployed) – Execution Components (created because of a executing system, such as a com+ object 36

UML Component Diagram • Used to visualize the static aspect of system • Specify relationship and details for construction • Contents – Components – Interfaces – Relationship such as generalization, association – Notes – Constraints • Generally, It’s a collection of vertices and arcs 37

A Component Diagram 38

Component Diagram : Application • • To model source code To Model executable releases To model Physical Database To Model Adaptable System 39

Deployment Diagram • Node : is a physical element that exist at runtime and represent a computational resource, generally having some memory and processing capability • Are used to model the topology of the hardware on which your system executes • UML representation databaseserver 40

Nodes Vs Component • Both have names • Both may participate in dependency, generalisation associations • Both may be nested , have instances • However Components participate in execution of a system whereas Node execute components 41

Deployment Diagram kiosk <<10 -T Ethernet>> server console RAID Farm <<RS – 232>> 42

Deployment Diagram 43

Draw a deployment diagram for a full fledged website to be hosted for your college. Make suitable assumptions. Main Server kiosk Student Webserver 1 : admission kiosk Visitor : college information Webserver 2 Examination results kiosk Staff attendence faculty 44

Example • A University wants to computerize their registration system – The Registrar sets up the curriculum for a semester • One course may have multiple course offerings – Students select 4 primary courses and 2 alternate courses – Once a student registers for a semester, the billing system is notified so the student may be billed for the semester – Students may use the system to add/drop courses for a period of time after registration – Professors use the system to receive their course offering rosters – Users of the registration system are assigned passwords which are used at logon validation 45

Actors • An actor is someone or some thing that must interact with the system under development Registrar Professor Student Billing System 46

Use Cases • use case is a pattern of behavior the system exhibits – Each use case is a sequence of related transactions performed by an actor and the system in a dialogue • Actors are examined to determine their needs – – Registrar -- maintain the curriculum Professor -- request roster Student -- maintain schedule Billing System -- receive billing information from registration Maintain Curriculum Request Course Roster Maintain Schedule 47

Use Case Diagram Request Course Roster Professor Student Maintain Schedule Billing System Maintain Curriculum 48 48

Sequence Diagram : Student registration form registration manager math 101 section 1 1: fill in info 2: submit 3: add course(joe, math 01) 4: are you open? 5: are you open? 6: add (joe) 7: add (joe) 49

Collaboration Diagram 1: set course info 2: process course form : Course. Form 3: add course : Registrar the. Manager : Curriculum. Manager a. Course : Course 4: new course 50

Classes Schedule. Algorithm Registration. Form Registration. Manager Course Student Professor Course. Offering 51

Classes Schedule. Algorithm Registration. Form Registration. Manager add. Student(Course, Student. Info) Course name number. Credits Student open() add. Student(Student. Info) name major Professor name tenure. Status Course. Offering location open() add. Student(Student. Info) 52

Relationships Schedule. Algorithm Registration. Form Registration. Manager add. Student(Course, Student. Info) Course name number. Credits Student open() add. Student(Student. Info) name major Professor name tenure. Status Course. Offering location open() add. Student(Student. Info) 53

Multiplicity and Navigation Schedule. Algorithm Registration. Form 0. . * 1 Registration. Manager add. Student(Course, Student. Info) Course 1 0. . * Student name number. Credits open() add. Student(Student. Info) major 1 3. . 10 Professor tenure. Status 4 1 1. . * Course. Offering location 0. . 4 open() add. Student(Student. Info) 54

Inheritance Schedule. Algorithm Registration. Form Registration. Manager add. Student(Course, Student. Info) Course name number. Credits Registration. User name Student open() add. Student(Student. Info) major Professor tenure. Status Course. Offering location open() add. Student(Student. Info) 55

State Transition Diagram Add student[ count < 10 ] Initialization Add Student / Set count = 0 do: Initialize course Open entry: Register student exit: Increment count Cancel [ count = 10 ] Canceled do: Notify registered students Cancel Closed do: Finalize course 56

Component Diagram Register. exe Billing System People. dll User Course. dll Course Student Course Professor Course Offering 57

Deployment Diagram Registration Database Main Building Library Dorm 58

Activity Diagrams - Swim Lanes Activities are arranged into vertical zones delimited with dashed lines. Each zone represents a broad area of responsibilities, typically implemented by a set of classes or objects. For example, the swim lane labeled accounting could represent objects of several classes (Bookkeeper, Clerk, Mail. Room, Accountant) working in concert to perform the single "cut paycheck" activity. 59

Thank you Prof. Anil Thakur B. Tech (Electronics and Computer Science) 79. 3% Microsoft Certified Solution Developer (MCSD) Email: email_anil@rediffmail. com http: //members. rediff. com/anilthakur Call : 33485196