Design Notations & Methodologies

1. Design Notations & Methodologies

2. Data Flow Diagram(depicting flow of data among components) Source or Destination of Data Flow of Data Processing Data Store

3. Example of DFD Packaging Instructions Inventory Info Shipping Instruction Order Process Order Customer Package Order Invoice Customer Info

4. State Transition Diagram( A notation to model the transition of states of a systembased on some stimuli ) 0 Initial Read 1 End 0,1 0 or 1 will change the system state from Initial to Read; 0 will keep the system at Read state; 1 will change the Read state to End

5. A More Design Oriented Representation Search again Check seat availability Display all airlines with available seat Start Function Z All airlines searched Search today’s flights to destination x Terminate search Not all airlines searched Terminate Function Z

6. Petri Net(A mechanism to depict “parallel” processing with condition node, event node, tokens, and arrows) OK Design Approval doc Rev. Results Req Inspection Rework Plan Not OK A token is placed into the condition Node (oval) when the condition is met; When all the conditions are met, the event Node (bar) is fired; All the tokens are moved to the condition node following the event node.

7. Entity Relationship Diagram (ERD) • ERD was introduced as a technique to model Data Conceptual Model about 20 years ago, before introduction of OO, when it was realized that both data and functionality need to be considered together. • Description of Data Types • Relationship among Data • Constraints on Relationship • From the ERD diagram, the Next step is Logical Database Design where ERD is mapped into Database Schema. • ERD May be used with OO techniques in designing Classes

8. Constraints on Relationship (cont.) • Modality (or participation or existence) specifies whether the existence of an entity depends on its being related to another entity via the relationship: • Total : Every entity of the entity type participates in the relationship • Partial : Some of the entities of the entity type may participate in the relationship write Author Book Author (Partial) because not all authors have written a book. Book (Total) because every book is written by an author

9. Cardinality and Modality Representation m 1 Writes Author Book Cardinality of 1 ( author) to (writes) many (books) Author Book (mandatory) (optional) Modality specifying that an author is mandatory for each book, but book is optional for author because some author never wrote a book

10. Object Oriented Notations • Use Case Diagram • Object Diagram (Static) • Object Relationship Diagram (Dynamic) • Sequence Diagram (Dynamic)

11. Use Case Diagram from UML • A scenario is a sequence of steps describing an interaction between a user and the system • e.g. (a scenario for purchasing) : a) user picks item(s) type and fills in quantity number(s), b) user receives total price, c) user receives confirmation number. • Use Case is a set of scenarios tied together by a user. • e.g. (a use case for on-line purchase) : scenario 1) user chooses purchasing option; scenario 2) user provides customer information and financial information; scenario 3) user purchases items. • A Use Case Diagram is a graphical representation of the use cases. It represents an external view of the system.

12. USE CASE Diagram (graphically) Actor - interface (human or another system) Use Case - processing or function Association Extend Relationship

13. Use Case Diagram for Requirements Gathering Gather Reqs Analyst Verify Reqs User/customer <<includes>> Prototype Specify Reqs Manage Reqs Rectangle is the system boundary Proj. Mgr.

14. Comments on Use Case Diagram • Each of the use case may be further refined. • The use case, itself, may be described via English or some other specification language separately. (Later in the design, the use case turns in to class diagrams, sequence diagrams, etc.) • Statements about system characteristics and other non-functional requirements may be described with each use case or within the system boundary rectangle. • * Use Case and Scenarios are “a natural” for developing test scenarios and test cases.

15. Class (Object) Diagram General Form: Example : Name of Object employee Attributes of Object • Employee number • Employee name • Cell phone • Input Emp_Numb() • Input Emp_Name() • Input Emp_Cell() • Find Emp_Numb() • Find Emp_Name() • Find Emp_Cell() Methods (functions)

16. OO Design - Classes and Objects • Identifying the classes for the solution, which may have started as early as the requirements analysis phase. • There is no formal method to do this • some suggestions include looking at the “nouns” used in expressing the requirements (Think of the Library System, again - what may be the classes ? - books, students, faculty, etc.) • To show the “static structure” of the solution, the relationships of the classes need to be specified. • Associations - Generalization or subtype (part of) Lib-Items Check out students books 0…m 0…m …. CD’s books periodicals

17. OO Design - Classes and Objects • In defining a class, one is to think about : • name of the class • attributes of the class • behavior (functions or methods) • After some preliminary identifications of the classes and static relationships, the attributes and the behavior portion of each class may become “clearer” and thus modified. • What are the attributes that make sense for books and not for CD’s ? • Which attributes are inheritable from the “parent” class, Lib-items ?

18. Represent Performance Requirement and Design Object 1 Object 2 Object 3 Invokes an object 2 method Invokes an object 3 method A (B-A)<2sec. Return B This is the performance specification of 2 secs.

19. Miscellaneous Diagrams • Hierarchy Diagram : depicts “calling” or “Transfer of control” structure of system • Control flow Diagram: depicts ‘control structure” or “control flow’ of code • Lattice Models: A mathematics model for set and relations (not used in software development ---- do not worry about this one)