Design Use Cases
Use cases from the perspective of what the system needs to do to achieve functionality described in the corresponding Use Cases
Design Use Case vs. Use Case
The workflow is different. Design use cases need info essential for implementation (i.e CRUD queries, creation of objects)
Layered Architecture
Presentation Layer, business logic, data access layer, database
Presentation Layer
The layer of code processing input from screens
Form classes - perform form validation without database access (calls action classes);
Action classes - Perform user requested action with valid data
Business Logic
High level functionality invoked from the presentation layer
Dispatch classes - perform validation with database access (send flow of control to manager classes to process data or to error handling)
Manager classes - manages data access objects (calls dat
Data Access Layer
Low level database interface methods invoked from Manager Layer (Add to database, no data validation)
Database
Database connectivity code
Aspect oriented software development
Code that spans all aspects of the project (supporting functionality, ie error procssing, calls to audit system -- made from all manager classes)
Test driven development
Failing test is written to verify new functionality
Code is only written to pass test
Code is refactored into code base with acceptable standards
Code is only written to past tests
TDD Pros
More tests written
Programmers more productive
Less need for debuggers
Drives design via tests focusing on customer interaction with system
Limits defects in code shortening implementation time
Resultant code is modularized, flexible and extensible
Automa
TDD Cons
Difficult to use when functional tests determine success/failure of system (ie UI)
Not all managers are believers
Tests must be maintained as part of project overhead
Refactoring or design changes may result in many changes to test
Developer and test auth
Software Development Cycle
Requirement analysis; design; coding; unit testing; integration testing; formal/acceptance testing; maintainence
Waterfall
Project is divided into sequential phases, with some overlap and splashback acceptable between phases
Emphasis is on planning, time schedules, target dates, budgets and implementation of an entire system at one time
Tight control is maintained over the li
Code reviews
Systematic examination of computer source code
Software Inspection
Peer review by trained individuals looking for defects using a defined process
Inspection Roles
Moderator - leader and coordinator of code review (not PM, rotate among team)
Reader - reads the document aloud to the group (not code author)
Author - person who wrote code
Recorder - Documents defects found (except semicolons and parenthesis)
Inspector
Requirements
Functional requirements describe a function that a user wants (display screen == implementation detail)
Terms must be specific, testable
No "ifs", "whens"...use "shall"
No "whys". no motivation of functionality
Numbered
Will / shall
Shall --> state device or system's requirement
Will --> State a device or system's purpose
Separation of Concerns
A design principle for separating a computer program into distinct sections
A program that embodies SoC well is called a modular program
The value of separation of concerns is simplifying development and maintenance of computer programs.
Model
The data model, the business rules
View
The presentation of data to the user
Controller
The interaction between model and view
Agile
Iterative and incremental development
Requirements and solutions evolve via cross-functional self-organizing teams
Adaptive planning rather than predictive planning
Flexible response to changes
Software delivery is the measure of progress
Scrum
Implementation of agile
Scrum Sprint
basic unit of development over a fixed time period (typically two weeks)
-Planning meeting - tasks identified, estimated time commitment
Daily scrum meeting - what did you do? what do you plan to do? what are your impediments?
Sprint review/ retrospective
Sprint backlog
Items needed to be done, prioritzed by risk, business value, dependecies
Burndown chart
Chart of work left to do vs. time
Scrum roles
Product owner - represents stakeholders and is the voice of the customer - not scrum master, often PM
Development team - self organizing, w/ cross functional skills responsible for delivery
Scrum master - facilitator, removes impediments, buffer between t
Pair Programming
Two developers work together at one station( driver - codes; observer/navigator - reviews each line as typed); Switch roles frequently
Pair Programming Pros
Shorter programs with better design, fewer bugs
Reduction in defect rates
More design alternatives considered
Catch design defects early
Arrive at more maintainable designs
Complete work faster
Difficult problems easier when working together
Best suited f
Pair Programming Cons
Total programmer time increases
For simple tasks, net drop in productive
MVC
software architectural pattern for implementing user interfaces. It divides a
given software application into three interconnected parts, so as to separate internal
representations of information from the ways that information is presented to or
accepted
Functional requirement
The system/user shall do <requirement>
Non-functional requirement
The system/user shall be <requirement>
MoSCoW
Must have; should have; could have; won't have