Intro To Design 1 Elementary School Library: User Sub-System Class Diagrams Software Engineering CSCI-3321 Dr. Tom Hicks Computer Science Department

"Good Design Is Good Design" Language Independent! Data Independent  Database Table Direct Access File  Text File Should Not Have Multiple Copies Of Redundant Data  Never Makes Sense To Lock & Change Multiple Records When We Could Lock & Change One Record!

Select A Team Recorder  Take Really Good Notes During Lectures

Begin With The End In Mind!

Your Application  3+ Simple Sub-Systems & 2+ Transactions All applications will need several forms. Most users will prefer you bind them in an MDI (Multiple Document Included Container)

You Will Need An Easy/Obvious Way To Get To Your Forms MenuStrips Will Help! Always Save The User As Many Clicks As Is Possible!

MDI Containers Can Have A Background Select A Good, Professional Background For Your Application

Sub-Systems Must Have Navigation Buttons You Will Need Navigation Buttons  Buttons Need Not Look Like = = = = = = = > Must Have: Next: Go To The Next Logical Record Previous: Go To The Next Logical Record First: Go To The First Logical Record Last: Go To The Last Logical Record

Use Good Tool Tips On Each & Every Button Navigation Buttons Download/Make Your Own - HOPE THEY ARE BETTER THAN MINE! Use Use Good Tool Tips On Each & Every Button

I have found that Users like Quick Link Buttons!

Class Diagrams Help Identify Data

Use Excel For Class Diagrams We Want To Identify & Organize All Of The User Information For Folks Checking Out Books, Magazines, Tapes, ETC. Non Students?

Must Be Able To Uniquely Identify Each User ID  Auto Incrementing Primary Key? May Seem Database Related  BUT IT IS NOT! CAN DO WITH Direct Access Files, ISAM, BTrees, etc.

We Need A Name Field Right? If Only Name Field!

First & Last Name Should Be Separate Fields Order Records By Name  Like Phone Book! Database - Don't Store Multiple Pieces Of Info In A SIngle Container

Search By Name Search By First Reports Order By Name  Like Phone Book!

All Of Us Are Going To Include Name Info

Better Yet All Of Us Are Going To Include Name Info

Now Suppose I Included A UserType Field Student Teacher Librarian Parent Take 1 Minute With Your Team List Different User Types For The Elementary School Library Application

Class Diagrams Done For Stakeholder Done For Developer Team

Most Software Engineers Include The "Brief Class Diagram" Which Are Required? What Type Of Control On The Screen? Default Values?

Class Diagram:Detailed  My Preferences Students Teachers Students Teachers Librarians Guests Students Teachers Librarians Parents Guests Lots Of Options On What To Include

Select Filters  Help You Drill Down Into The Data SELECT * FROM Users WHERE UserType Like "Guests";

If You Hard Code Data Into Combo Control  Change? 3] If You Hard Code The Filter, It Would Require A Programmer To Modify The Code To Change It  YUK! 4] Numeric Queries Are Much Slower Than Text Queries - Whether You Use A Database Or Not! SELECT * FROM Users WHERE UserType = 3 ?

This Design Stinks! 1] Software Engineer Is Expecting Users To Know All The Choices For UserType! Students Teachers Librarians Parents Guests 2] Software Engineer Is Expecting Users To Be Able To Spell The Choices Correctly!

"Good Design Is Good Design" Store The Data  Database Table  Direct Access File  Text File API  Application Programming Interface We Can Fill ComboBox Controls (Web/API) With UserTypes  Selection Return A String Fill Control From Query Or Array Fill With One Item  UserType  Return String Fill With Two Items  UserType & ID  Return Numeric

Populating The Combo Control Is Generally 1 Line Of Code! Suppose We Use A Database : Data Entry Field For User Connecting To The Database Is Generally 1-2 Lines Of Code! Populating The Combo Control Is Generally 1 Line Of Code! Data Entry

Populating The Combo Control Is Generally 1 Line Of Code! Suppose We Use A Database : Filter Connecting To The Database Is Generally 1-2 Lines Of Code! Populating The Combo Control Is Generally 1 Line Of Code! FILTER

UserTypes Interface ? One Of The Teams, Last Year, Did A Complete Sub-System Interface (Next, Previous, First, Last, Edit, OVER-KILL  Too Much Work  UserType Is A Supporting Class

More Appropriate UserTypes Interface ? No Re-Programming!

UserType Is A Supporting Class Of User A Supporting Class May Support More Than One Class  Great Idea To Provide

Class Diagrams: Detailed Detailed Class Diagrams Can Occupy A Lot Of Real Estate?

What Type Of Control? What DataType? Back To Class Diagram What Type Of Control? What DataType?

User Sub-System Class Diagrams: Brief As You Meet With Your Stakeholder, You Go Through The Fields In The UserType  "What Have I Missed" - Additional ?  "What Do I Have That You Don't Want?" It Would Be Good To Show  So That They Would Have A Better Understanding Of UserTypes! OR  Them Might Even Add Additional Options To Data