CSC
440 Midterm Study
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.
· 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
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 Outline - general
picture and architecture
l Sprint cycle -
Specify/ develop and validate and deploy
in increments; daily 15 minute meetings standing up
l Final version plus
documentation
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 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 prog
§ 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
§ External
² context and environment (context model - line and box or package)
§ Interaction
² Between system and its external environment
(use case)
² Between the components of a system. (sequence
diagram)
§ Structural
² organization of a system (class diagram)
§ Behavioral
² Response to events (state diagram, activity
diagram)
²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
· Stimulus : Events as labeled arcs connecting
states
· Superstate to group for arcs that apply to many
states
§ 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
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?
² 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?
² Are there objects that do not correspond to
entity objects?
²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
²When developing software, you should always
consider the possibility of reusing existing software, either as components,
services or complete systems.
² Design patterns - just know they exist
²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.