Phase 1 Template:
Please use this template as a guide for what to submit for phase 1 report. Include team number, class, and current term in the header for all
pages (show above).
For your p1_report.pdf submission, please follow this order:
• Table of Contents
• Data Types
• Business Logic Constraints
• TD/AC for each Task including oval diagrams for each task on remaining pages of report
Table of Contents:
Datatypes, Constraints, Task Decomposition (TD), and Abstract Code (AC) for each task working navigation links.
Data Types:
Include data types for all attributes in your EER diagram. In this phase, SQL datatypes such as VARCHAR should not be used. The
datatypes listed should be simple datatypes such as integer, string, Boolean, and float for single-value attributes, and for multi-value
attributes, you should use list, collection, or single-dimension array with the individual element data type properly reflecting the data
being stored. You should also indicate if NULLs are allowed for the attribute.
Make sure to recognize when to appropriately store certain kinds of data (such as phone numbers, quantities, or zip codes. See this for an
example.) In this phase, do not create database tables or any kind of database schema, so do not include any surrogate keys, foreign keys,
or any data types that represent them.
In phase 3, you may optionally implement 'best-practice' security safeguards (password hashing, SQL injection prevention, etc.), but you
should not model them in phase 1 or phase 2.
Business Logic Constraints:
Include applicable business logic which cannot be represented sufficiently in the EER diagram.
Task Decomposition:
Include the rules of thumb outlined in the lectures for each task and determine if a mother task is needed (lock types, enabling conditions,
frequency, schemas, indices, consistency, and subtasks). Task names on the IFD should match those in the TD. Please follow the report
names provided in the requirements document, so TAs can easily follow your logic.
Per Leo Mark: "The rules of thumb for task decomposition give you an indication of whether to sub-divide or not. You stop the
decomposition when no more decomposition is called for by the rules. You need a mother task if the sub-tasks need to be sequenced, all
executed together as an atomic unit."
Per Jay Summet: “If your task has no sub-tasks you would only have the single oval in the IFD and the abstract code in the report. If your
tasks do have subtasks, then you show how it breaks down and show the abstract code for each subtask in the report.”
Abstract Code:
Your abstract code should handle basic data validation (example: user cannot enter string for an int datatype) and basic error handling
(example: user types in wrong password what happens?). Consider the IFD forms to be like web-page user interfaces where the user
clicks on buttons or types input fields. Walk us through how you get to each task and how you leave each task to get to the next one.
Include consistent markup to convey meaning (bold, italic, underline, etc.). Include the words ‘task’, ‘form’, and ‘button’ (or similar)
after every use in your abstract code so there is no confusion on intent. Note: application variables like '$UserID' are optional
depending on your language- PHP, Python, Java, Ruby, etc. Make sure your abstract code clearly describes how a variable is assigned!
Markup something similar to:
Bold Underline: Form Example: Main Menu form
Bold Italics: Buttons Example: Save button
Bold: Task Example: Login task
Italics: Form Input Fields: Example: username, model, cost, etc.
…etc.
Please do not put TD and AC side-by-side, TD before AC sections in order are allowed.
Lastly, use this as a guide so the grading process will be faster. Feel free to post a private question: (Team0## + Instructors) if you need
further clarification for your project.
Thank you in advance,
CS6400 Instructional Team
