Structured Modeling

1
Structured Modeling

• CS 123/CS 231

2
Models

• Data Model
• Entity-Relationship Diagram
• Process Models
• Data-Flow Diagram
• State Diagram
• Structured versus Object-Oriented Modeling

3
ERDs

• Entity-Relationship Diagrams
• Used to produce a data model for an enterprise
• Database Design

4
Entities and Attributes

• Entity
• thing, person, place
• examples Book, Sales Invoice, Student,
  Customer, Employee, Department, Airport
• Attribute
• feature of an entity
• examples Name, Address, Age, QCA, Title,
  Author, Amount, City

5
Relationships

• Relationship
• an association between (at least) two entities
• examples student borrows a book
• Cardinality
• One-to-one, one-to-many, many-to-many
• Intersection Data
• attribute resulting from relationship
• example date-borrowed

6
The Notation

• Rectangles - Entities
• Ellipses - Attributes
• Diamonds - Relationships
• Links
• Labels

7
Example The University Setting

• Description
• Students enroll in classes. Each class is a
  section of a particular course.
• Entities
• Student, Section, Course

8
address
name
year
id number
qca
Student
9
room
index
sched
M
M
Student
enrolls
Section
M
grade
1
Course
has
cat num
desc
title
10
Example 2 Library

• Student borrows book
• many to many relationship between students and
  books
• see first diagram
• Further analysis reveals there could be several
  copies of a book
• student borrows copy, book has copy
• see second diagram

11
M
M
Student
borrows
Book
12
M
M
Student
borrows
Copy
M
1
Book
has
Exercise Complete Diagram by filling in
attributes
13
ERDs and the Software Life Cycle

• Used at the design phase of the software life
  cycle for database systems, although it is often
  used as early as the analysis phase
• In design, it precedes table definition

14
From ERD to Tables

• Create a table for each entity
• attributes associated to entity are columns of
  the table (a primary key should exist per table)
• For each 1M relationship
• add the primary key of the 1 participant as an
  attribute of the M participant (foreign key)
  intersection data is also added to the M
  participant

15
ERD to Tables, continued

• For each 11 relationship
• add primary key of one table plus intersection
  data to the other table
• For each MM relationship
• create a new table
• attributes are the primary keys of the
  participants plus intersection data

16
University Setting Example

• Student
• id number, name, address, year, qca
• Section
• index, room, sched, cat num
• Course
• cat num, title, desc
• Enroll
• id number, index, grade

17
DFDs

• Data Flow Diagrams
• Models Operations (Processes)
• Also used in analysis and design

18
Processes

• An operation or function in a system
• example Borrow Book
• Involves
• data flow (input and results)
• data sources and sinks
• Example student and book-copy info are data
  that flow into the process results stored in
  borrow table

19
Notation

• Circle (Bubble) - Process
• Arrows - Data Flows
• Rectangles - Sources and Sinks
• Labels

20
1 Borrow Book
id num, copy num
borrow confirmation
Student
Borrow
Copy
21
DFD Levels

• A process may involve sub-processes
• provides detail about the process
• DFD levels emerge
• Process hierarchy also depicted using a structure
  chart

22
1.1 Check Student Status
id num
borrower status
Student
1.2 Check Book Copy Status
copy num
copy status
Copy
23
borrower status, copy status
1.3 Record Borrow
borrow confirmation
id num, copy num
Borrow
Copy
24
About DFDs

• Data flows should balance between levels
• Number label format X.X.X provides level
  information
• Context Diagram
• Level 0 (or system-level) DFD
• Notational Variations

25
Summary

• Modeling techniques and notation
• needed in analysis and design
• models data and processes of a system
• Other techniques and notation
• state diagrams, structure charts, flowcharts,
  document flow diagrams, more...
• Unified Modeling Language
• for Object-Oriented systems development

26
Software Project Management

• CS 123/CS 231

27
Management Activities

• Proposal Writing
• Project Costing
• Planning and Scheduling
• Monitoring and Review
• Personnel Selection and Evaluation
• Reports and Presentations

28
S/W Process Activities

• Sec 3.3 (Activity Organization)
• S/W typically divided into activities
• Milestones describe progress at the end of an
  activity
• progress report
• internal or presented
• Deliverables are often part of a milestone

29
Project Scheduling

• Sec 3.4
• Scheduling involves
• separating total work into activities
• judging total time required
• Considerations
• parallel activities
• problem anticipation, regular sched updates
• resources other than time

30
Scheduling Notation

• Task Duration and Dependencies
• table or activity network
• Activity Bar Chart
• schedule, parallel activities
• depicts flexibility against schedule slippage
• Staff Allocation
• table or time chart

31
Risk Management

• CS 123/CS 231

32
Risk

• Something that can go wrong
• Caused by inadequate information
• Resolved by initiating actions that
• discover the relevant information
• reduce uncertainty
• Boehms Spiral Model
• explicitly integrates risk assessment and
  reduction

33
Risk Categories

• Requirements Risks
• Skills Risks
• Technological Risks
• Others
• Reference UML Distilled, Chapter 2

34
Requirements Risks

• Dangers
• building the wrong system
• misunderstanding priorities
• Dealing with the risks
• improve communication between analysts,
  developers, and clients
• enforce the discipline of using concrete,
  understandable models (e.g., use cases)

35
Technological Risks

• Dangers
• Unexplored software tools or techniques
• Lack of alternatives
• Dealing with the risks
• obtain necessary resources
• build working prototypes
• test integration capabilities (arch design)
• identify alternatives

36
Skills Risks

• Dangers
• Not enough personnel
• Not enough expertise
• Dealing with the risks
• training / reading / mentoring
• deliberate project scheduling

37
Your Class Project

• A designated representative of each group will
  meet me
• bring document on deliverable for Oct 5
• I may/will revise that document
• The group should meet to identify risks and deal
  with the risks
• ultimate goal prototype on Oct 5 should should
  incorporate all that was promised

38
Software Quality Managementand Process
Improvement

• CS 123/CS 231

39
Software Quality

• Quality Management
• Chapter 30 of Sommerville book
• Process Improvement
• Chapter 31 of Sommerville book

40
Process vs Product Quality

• Process Quality directly affects Product Quality
• Should measure both product and process
• Standards
• define characteristics that all product
  components should exhibit
• define how the software process should be
  conducted

41
Standards (Example)

• Product
• Design review form
• Document naming
• Procedure headers
• Programming style
• Change request form

• Process
• Design review conduct
• Document submission
• Version release
• Change control
• Test recording

42
Metrics

• Software metric
• type of measurement that relates to a system,
  process, related documentation
• Examples
• lines of code
• Fog index--readability of a manual
• number of reported faults

43
Process Improvement

• Definition
• Understanding existing processes and changing
  these processes to improve quality and/or reduce
  cost and development time
• Process Improvement Process (iterative)
• analyze process
• identify improvements
• introduce change, train personnel, fine-tune

44
The SEI CMM

• Capability Maturity Model (CMM)
• defines levels of maturity of software processes
• See Section 31.4
• Initiated by the Software Engineering Institute
  (SEI)
• for the US Dept of Defense
• goal assess capability of contractors

45
Five CMM Levels

• Initial Level
• no effective formal processes
• success dependent on individual capability
• Repeatable Level
• some formal processes exist
• can successfully repeat projects of the same type
• no formal process model

46
CMM Levels, continued

• Defined Level
• formal process model exists
• conscious of process improvement
• Managed Level
• quantitative measures
• process improvement based on metrics
• Optimizing Level
• deliberate, continuing process improvement

47
Testing

• CS 123/CS 231

48
References

• Debugging and Testing
• Reiss, Chapter 8
• Verification and Validation
• Sommerville, Chapters 22-24

49
Debugging Testing Definitions

• Bug
• a defect or error in a program
• Testing
• running a program with the intent of finding bugs
  (defect testing)
• Debugging
• determining the exact nature of a bug

50
Types of Bugs

• Syntactic Bugs
• syntax errors, typos
• Design Bugs
• Logic Bugs
• Interface Bugs
• method invocation versus definition
• Memory Bugs

51
Steps in Debugging

• Locating the problem/cause
• the more difficult step (in general)
• use inductive/deductive reasoning
• Repairing the problem
• if design bug, consequences are often extensive
• note that solution may result in more bugs
• regression testing

52
Defensive Design

• Simplicity
• in class interfaces
• in algorithms
• Encapsulation
• minimizes coupling increased correlation between
  locations of error and cause
• Error-handling
• design with error in mind

53
Defensive Coding

• Writing code to simplify debugging
• What to watch out for
• initialization
• method preconditions (check for valid parameter
  values) and return value cases
• complex code / bug history
• Language support
• assertions (in C,C - assert.h), exceptions

54
Reviews

• Particularly for large projects with several
  designers and programmers involved
• Design Review
• presentation to other developers, stakeholders,
  and outside consultants
• brings out other, external perspectives
• Code Review
• walk through your code, line by line

55
Debugging Tools

• Controlling execution
• breakpoints, tracepoints, watchpoints
• single-step execution
• Observing execution
• watches (displays)
• view execution stack, view memory
• Alternative inserting print statements (!)

56
Testing

• May be performed at different levels
• Static Testing
• testing without program execution
• code review, inspection, walkthrough
• Dynamic Testing
• module testing, integration testing
• system/regression testing
• black-box vs white-box testing

57
Stages in the Testing Process

• Unit Testing
• Module Testing
• Sub-System Testing
• System/Integration Testing
• Acceptance Testing

58
Testing Strategies

• Top-down testing
• Bottom-up testing
• Thread-testing
• Stress testing
• Back-to-back testing

59
How to Test

• Devise Test Plan
• clear/consistent procedure/standards for testing
  a system
• Identify Test Cases
• thorough listing of possible inputs
• include boundaries, invalid/unexpected inputs
• Implement the Test
• write test code (test drivers), use testing tools

60
Test Cases

• Equivalence Partitioning
• partition input ( output) into classes that are
  processed equivalently by the program
• Test Case Guidelines
• Example for arrays, consider varying sizes, test
  for first, middle, and last element
• Path Testing
• based on possible execution paths white-box