CSC 440 Final Study
I removed what is in purple
Why are we doing this?
· Prepare for the process surrounding your senior project.
· Provide knowledge of project management and design processes that will help you impress an interviewer, complete projects and rise in a corporation.
· Help you talk in UML, naturally reaching for a UML design as the best way to illustrate what you want to say to a user or another programmer.
· Learn to do the design needed of an entry level programmer, given a system spec, or even a technical design spec, and producing a solid class level design.
· Understand how the user needs fit into the project documents, whether you are in a plan based or incremental based shop so that you can be considered a top user interactor.
· Know how to not only read project documents, but to write them, so that when you are given a chance to design, your understanding of the project will flow out onto paper so others will know you can analyse and manage projects.
Major goals covered by the final:
· Project delivery - Mysql and Junit and GIT - just enough to do the project
· Diagrams (new details on the class diagram & firm state, use, context, sequence)
· Agile cycles with SCRUM management - live it (Sprint Cycles, Daily Scrum Stand Up meetings, Burn Down charts, and Product backlog refinement.)
o XP features: (pair programming, test driven development (junit tests), code refactoring and use of user stories and user acceptance tests)
· Assigning man hours and tracking completion -> burndown chart (did not do Gantt chart or Critical Path)
· Testing Levels + How to write a test case
· Configuration Management and change control using GIT
· Design classes use design patterns
· Security considerations to your design
Major goals covered by the midterm:
· Understand waterfall and agile (and scrum) software engineering methodologies, including their major steps and advantages.
· Know how to write a professional requirements specification with user requirements and system requirements aimed at the appropriate levels. (At this point, the requirements are still rudimentary, but aimed at appropriate levels.)
· Know how to create 5 UML diagrams: Context, Use case, Sequence, Activity and State
· Know how to create a class diagram given a requirements specification. This means knowing how to use CRC cards, Use Cases and Scenario descriptions and written system requirements to determine first broad entities and then actual classes to code.
· Know how to elicit user requirements using scenarios, use cases, ethnography and interviews.
· When given a system description, be able to write user requirements, system requirements and determine the optimum system architecture.
· Know how to turn to the Software Engineering Code of Ethics and Professional Practice to resolve uncomfortable issues in your workplace.
Lots of details extracted from lectures
Software Process - overview of models for
entire System Engineering approach
l
Software Process Activities
(Common to all methods)
‘
Specification defining what
the system should do;
‘
Implementation (development)
defining the organization of the system and implementing the system;
‘
Validation checking that it
does what the customer wants;
‘
Evolution changing the system
in response to changing customer needs.
l Software Process Models
‘ Plan based Waterfall
l Requirements / system design / implement (code/unit test) / integration (system test) / maintenance
l Advantages
l Big picture is developed up front so coding time is not wasted (no need for Agile's refactoring)
l Users have more up front involvement and have to sign off that their requirements are understood fully before the project moves on to design.
‘ Incremental Agile
l Scrum Project Management
l Steps:
l Outline - general picture and architecture
l Sprint cycle lots of deliveries
l Specify/ develop and validate and deploy in increments;
l daily 15 minute meetings standing up to adjust burn down chart
§ Man hours
§
Planned vs Actual vs Earned
§ Track at person / task level with groupings
up to story level
§ Adjustments
§ Drop tasks
§ Adjust Acceptance Test Plan
l product and release backlogs yield tasks for the next sprint
l Write a user acceptance test plan
l User must accept the software
l Final version plus documentation
l Roles - Product owner, Scrum Master, Development team
l Ceremonies
l Sprint planning done (stories chosen)
l Sprint designed (tasks chosen with high level design)
l Daily Scrum Meeting
l Extreme Programming is one type
l 2-4 week regular delivery cycle
l Select user stories for release
l Break down stories to tasks
l Plan the next little release
l Develop / integrate / test
l Release software
l Evaluate system by stakeholders
l Pair programming
l Test driven design with continual retest and
integration
l Refactor code
l Agile Manifesto:
l Individuals and interactions over processes and tools
l Working software over comprehensive documentation
l Customer collaboration over contract negotiation
l Responding to change over following a plan
l Advantages
l The cost of accommodating changing customer requirements is reduced. (less analysis and doc)
l It is easier to get customer feedback on the development work that has been done.
l More rapid delivery and deployment of useful software to the customer is possible
‘
Reuse COTS (commercial off the
shelf)
l
Requirements / comparison to
existing -> changes to COTS system requirements Before the system design
‘
Boehms Spiral - Risk
l
Objectives / alternatives and risks / develop / plan next phase
‘
Rational Unified Process (RUP)
UML iterative phases
l
Good practices:
l
Develop software iteratively - customer priorities / deliver in increments
l
Manage requirements - document
initial and changed requirements.
l
Use component-based
architectures - make reusable when possible
l
Visually model software using
UML
l
Verify software quality
l
Control changes to software
l
Change management for
requirements
l
Configuration management for
code
Code
of Ethics
‘ Governs how a programmer should handle ethical dilemmas
Requirements documentation
² The software requirements document is an agreed statement of the system requirements. It should be organized so that both system customers and software developers can use it.
² Requirements elicitation techniques:
§ Interviews
§ Scenarios
§ use-cases
§ ethnography.
² Requirements Documentation
§ High level what, not how
§ Written in natural language or structured with graphs, diagrams and tables where possible
§ Validate document
§ Expect and manage changes
² Types of requirements
§ Functional requirements vs non-functional
² Functional: Services the system provides
² Levels of requirements
§ User requirements
² Purpose: Describe everything the user wants the system to accomplish. This can include non-functional requirements such as needing the system to respond to any command within 5 seconds
² Audience: Written for customers and business managers, not programmers
§ System requirements
² Purpose: How the system will implement the user's requirement, without giving detail design. Should include major entities, attributes and screens
² Audience: Technical design team, though users must be able to understand it. - not business manager, programmer will read this
² Validating requirements when done:
§ Validity. Do requirements match customer's real needs?
§ Consistency. Are there any requirements conflicts?
§ Completeness. Are all functions required by the customer included?
§ Realism. Can the requirements be implemented given available budget and technology
§ Verifiability. Can the requirements be checked?
§ How to check
² Requirements reviews
² Prototyping
² Test-case generation
Software UML Models
² Model Driven Engineering
§ Model-driven engineering is an approach to software development in which a system is represented as a set of models that can be automatically transformed to executable code.
² Types of models we used
² context and environment (context model - line and box or package) - External
² Between system and its external environment (use case) - Interaction
² Between the components of a system. (sequence diagram) - Interaction
² organization of a system (class diagram) - Structural
² Response to events (state diagram, activity diagram) - Behavioral
² Context model - position in the environment
§ Line and box or package
§ Boundary around what you are implementing
§ Include modules or subsystems
² Activity diagram - illustrate workflow to complete a task
§ Can be used to define high level business process or workflows
§ Shows how the system will be used at a high level
§ Order of activity made of many actions
§ Different from flowcharts - Support parallel behavior
§ Shows essential sequencing
§ Components
² Actions box - (can be a basis for another activity diagram)
² Process line
² Fork line - one in and several out - multiple actions can start
² Join line - close parallel actions - every action done by this line
² Condition diamonds - decisions
² Branch diamond - start conditional
² Merge diamond - join back to the flow
² Partition lines
² Illustrate which system does what
² Use Case diagram - who uses what in the system, or to complete one goal
§ Model discrete task - Set of scenarios with one goal
§ Actors (roles) may be people or other systems.
§ Diagram or Text
² Sequence Diagram - messages sent back and forth in a sequence
§ Sequence
during a single scenario or use case
§ The objects and actors (participants) at the
top
§ Dotted line drawn vertically (lifeline) from
each participant - rectangle for activation
§ Interactions between objects -> annotated
arrows
§ Do not illustrate algorithms, loops, and
conditions well
o Alt box - can handle conditions; conditions in [ ]
§ State Diagram - response to stimulus
· States - Determine states of being in the system and put them in rounded rectangles as nodes; choose state of being names not action names.
· Stimulus : Events as labeled arcs connecting states
· Superstate to group for arcs that apply to many states
· List of state and stimulus helps you think of all different states
· Some actions may happen inside states and not be stimulus for movement
· Look at each stimulus to see if it gets an arrow from that state.
· Not an activity diagram
· Label lines:
o Trigger : an action
o Guard (inside []) : a condition
o Transitional behavior (after /) : a message or variable setting
§ Class Diagram - classes and how they relate to other classes
² Cardinality
² Diamond to show aggregation - Diamond attached to the class that contains another class.
² Triangle - attached to the whole in an is a relationship.
² Small arrow - The class without the arrow knows the one with the arrow exists
² Dotted line - association
² To small arrow class with no arrow depends on the small arrow side
² To large arrow - class with no arrow realizes (implements or executes) the arrow side
² Annotations you will need are here: http://home.adelphi.edu/~pe16132/csc440/assignments/ClassAnnotationsYouNeed.html
Architecture:
²
Answers questions
²
Is there a generic
application architecture that can be used?
²
How will the system
be distributed?
²
What architectural
styles are appropriate?
²
What approach will
be used to structure the system?
²
How will the system
be decomposed into modules?
²
What control
strategy should be used?
²
How will the
architectural design be evaluated?
²
How should the
architecture be documented?
² Patterns
² Model View Controller
² Layered
² Models
² Central Repository (about where the data is stored)
² Client / Server (about where the processing work is done)
² Pipe and Filter (about how the data flows through a batch system)
²
Architecture box
diagram
²
Modules / subsystems
/ systems
Software Detail Design
² Goals:
² Performance - Response time, memory requirements, etc.
² Dependability - Robustness, availability, fault tolerance, safety
² Security
² Cost factors - Development, deployment, upgrade, maintenance, administration costs
² Maintenance factors - Extensibility, modifiability, portability, understandability
² End user factors - Utility and usability
² Methods to determine classes
² Reading specs for : grammar (repeated nouns for subject entities and repeated verbs for control entities), tangible objects, scenario controllers or behavior.
² Use case analysis: Look for entity, control and boundary objects. Can start with use case.
² CRC Cards can help define classes. Class / Responsibility / Collaborator
² Class refinement after you have candidates:
² Are all objects cohesive? (only one abstraction)
² Are any of the objects redundant?
² Are any of the objects irrelevant?
² Are any of the objects vague?
² Are any of the objects really attributes of other objects? (Is all data related to the same class?)
² Is all related data in the same class?
² Are there objects that do not correspond to entity objects?
² Is there any unnecessary coupling? (No printing to a specific device such as screen scanner unless device specific class)
² Good class design
² Fully trace to requirements
² Not Lots of related primitive types (extract address to its own class)
² Not Overly complex classes break it into two
² Self documenting class names
² Class detail design:
² Order elements consistently (such as constants, constructors, static methods, other methods, instance variables, static variables)
² Initialize data in a constructor
² Private data
² Subsystem and Component interfaces definition is necessary to divide work
² User interface document
² Configuration management is the process of managing changes to an evolving software system. It is essential when a team of people are cooperating to develop software.
Testing
Levels - unit (function level by programmer) / system (all modules by programmer) / user (all modules by user)
Structure - situation / input / expected output
TDD - (test driven design) code test before coding program
JUnit Tests
Create test case classes to test individual classes or small groups
Easy to hook test classes to the classes being tested
Test building tools inside Junit class
Easy to rerun one set of tests or all tests in the entire system.
Easy to supress tests in production
Choose cases - partitions (border, null, sample) / sequences / buffer limits / force errors
You will be able to :
Write a user acceptance test plan
Write good test cases on paper
Design Patterns:
² When developing software, you should always consider the possibility of reusing existing software, either as components, services or complete systems.
² Object Oriented Design patterns -
² Industry standards Gang of Four 23 patterns + Siemens + industry specific
² Contain: name, UML class diagram, motivation; description of how to implement; consequences
² Types we explored:
² Singleton purpose global instance of an object; maybe for your log file or database connection
² Observer purpose Separates the display of object state from the object itself, and let different responsibilities be handled with one common interface.
² Factory purpose decouple creation of objects with an inheritance structure
Security Requirements:
Types of Security Threats - confidentiality, integrity, availability
Ways to protect - avoid vulnerability (before) ; detect and neutralize attacks (during) , ensure recovery (after)
10 security requirements to consider
Identification - Whether a system should identify its users (for inquiry and/or change)
Authentication - how to identify users
Authorization - who can do what
Immunity - how to protect against malware
Integrity - How data corruption can be avoided
Intrusion detection - what mechanisms should be used to detect attacks
Non-repudiation requirements - ensure every party in the transaction must admit its involvement
Privacy - keep data private if it should not be shared
Security auditing - how to audit and check that the system is secure
System maintenance - prevent unauthorized changes to production systems
Weigh risk and level
of issue a break would cause
Security design
guidelines
Base security
decisions on explicit security policy - write it if it does not exist
Avoid a single point
of failure
Fail securely
Balance security and
usability
Log user actions
Use redundancy and
diversity to reduce risk
Validate all inputs
(buffer overflow, sql injection
)
Compartmentalize
your assets
Design for
deployment
Design for recoverability