COSC 202 general

console

initial input/output device for a computer

what is git

tool to track changes to sets of files

what are git repositories

maintain code history, have commits of tracked files(nodes), edges record how nodes emerged, decentralized version management system, every member has repository of complete graph copy and these are synched

abstractions of git

web browser(github), graphical IDEs(Netbeans), command line git

sdlc and problem solving

organization recognizes problem, project team investigates/understands problem and solution requirements, solution is specified in detail, system that solves problem is built, system installed, used, maintained and enhanced

waterfall models: traditional predictive approach

assumes phases can be done sequentially, once a phase is done you fall over the waterfall to the next

modified waterfall models

reasonably thorough plan, project phases can overlap to influence each other, can go back if not fully thought out

concepts of adaptive approaches

incremental development, walking skeleton(built with bare-bones functionality)

generic adaptive approach

6 core processes span iterations with multiple iterations as needed, project focuses increase or decline as iterations progress(identify, plan, detail, design, build+test, deploy)

agile development

set of guidelines to develop information systems in unknown, rapidly changing environments, chaordic, 12 modelling principles

agile modelling principles

build only necessary models that are useful and at the right level of detail, incremental change, focus on stakeholder needs, adapt to specific project needs

four life cycle phases of unified process

inception, elaboration, construction, transition

inception unified process

what the system is going to be doing, cost to build, how long it will take to build

elaboration unified process

refine requirements and establish system architecture

construction unified process

build and test the system iteratively

transition unified process

deploy the system to users

product owner

client stakeholder who controls backlog

scrum sprint

a time controlled mini project to implement part of the system, scope can’t expand, time period is constant, daily meeting

properties of good quality requirements

understandable, complete, consistent, correct, unambiguous, testable, feasible, atomic

consequences of poor quality requirements

system delivered late and over budget, doesn’t meet customer needs(dissatisfied or scrapped), higher maintenance-related costs, unreliable or non-functional

causes of poor quality requirements

problem not well understood, misunderstanding between stakeholders, insufficient training, experience or access to stakeholders, evolving requirements, incomplete information, ambiguity, inconsistency

contents of requirements document

system services and functions, constrains for system operation and development, emergent system properties, application domain info, system environment. essential that doc is confirmed and signed off by stakeholders

requirements in unified process

elicited, modeled and refined during inception, elaboration and construction. implement functional before non-functional

requirements in extreme programming

based on user stories over individual requirements, continuous involvement of users who decide about functionality and scope

requirements in scrum

requirements owned and operated by product owner, only use user stories if create structure to product backlog

what is requirements elicitation

process of an analyst gathering information on what a system should do from as many sources as possible

ways to classify stakeholders

internal(within org, employees), external(outside org, suppliers), operational(interact w/system, customers), executive(use information or have financial interest w/o interacting, board of directors, investors)

information gathering from existing systems

need to identify deficiencies to be addressed in new system, don’t waste time and effort to reimplement same stuff, balanced review of current functions and new requirements

information gathering from models

primary output of requirements phase is large collection of models, learn more about problem by modelling, abstraction can reduce complexity, document all details, useful for communication between stakeholders and developers

what is review existing materials

obtain preliminary understanding of processes, use as guidelines to guide interviews, identify rules, discrepancies, exceptions, redundancies

interviews and discussions with users

effective way to understand business functions and rules, can prepare questions or have open discussion, may require multiple sessions, individuals or groups

pros of interviews

free and open answers, can ask follow up questions to gain insight or clarify answer, interviewee actively contribute

disadvantages of interviews

time consuming and resource intensive, success dependent on analyst communication skills, location or schedule can make it impractical

observe and document business processes

walk through or shadowing, may make users nervous, document using workflow diagrams, don’t need to observe all processes to same detail level

build protoypes

preliminary working model of larger and more complex system, accomplish one objective, build quickly, test concepts, evaluate look and feel

questionnaires

limited and specific info from many stakeholders, preliminary business insight, not for high detail, closed-ended for direct answer or open-ended questions for elaboration

research vendor solutions

take advantage of existing knowledge and solutions, can avoid costly mistakes and save time and money, risky to buy before requirements are fully known

advantages of researching vendor solutions

Helps users generate new ideas about how best to perform business function, existing solutions could be excellent, often cheaper and less risky to buy than build

validating requirements

essential, ensure info is correct, implement quality control early, review findings and models, project manager responsible for system quality, review conducted by analyst and stakeholders, review after document creation

revisiting requirements

independent, identify which to implement not when, iteration includes a requirements collection and prioritization activity. Scrum: product backlog, UP: inception and elaboration, XP: user stories

why is eliciting requirement difficult

users unable to articulate, ignorant of tech, may contradict each other, language barriers between analyst and user, need multiple user sources to understand, analyst lack skills to obtain requirements

why UML

helps develop effective and correct designs, better communication w/stakeholders, big picture view of project, independent of programming language, standard for OO system modeling

what are use case diagrams

high level view of what a system does and who uses it, represents users perspective, mainly in requirements specification, to-do list, specifies participants and relationships in use cases

benefits of use case diagrams

informal, simple, flexible, easy to construct, easily understood by users and developers, improves communication, can be used to confirm requirements, provide good overview of functionality, link analysis to design, used to infor subsequent development tasks

actor

roles that people have when interacting with the system(employee), external systems or hardware that are essential to system operation(paypal)

use case

a discrete unit of system functionality, activity from actor perspective

extend dependency

use case has optional subordinate tasks that extend functionality when needed, useful for specialized actors(international student needs visa check to enroll at uni)

include dependency

mandatory, subordinate tasks that can occur in any order(enroll at univeristy includes issue id card)

require dependency

mandatory, independent tasks that must be completed first, forces sequence(log in requires authentication of user)

inheritance

via specialization: subclass, subtype. subclasses inherit public state and behavior, can override superclass behavior

inheritance via specialization

subclasses inherit all public members, can replace or customize inherited method, can add specialized method, can’t be subclasses of anything else

inheritance via interface implementation

public methods and constant fields, specifies common behavior, can implement multiple interfaces, no implementation in interface

class diagram

structural aspects of an OO system(class types, class relationships, class fields and methods), used throughout development process

stereotypes in class diagrams

add further meaning or clarification, can be attached almost anywhere, field-«unique» class«abstract» «interface»

Association names

association-verb phrases between classes(assigns,reserves)

Role names

indicates role of class in association ex. reserved by (conceptual), implies field in class opposite, includes visibility(implementation)

Navigability

whether you can follow an association from one class to another, which class has reference or can access another class. Always include relevant role names. who can access whom

aggregation

one class is made up of one or more other classes, container and content instances can exist seperately

composition

stronger form of aggregation, container and content instances cannot exist separately, multiplicity of at least 1 at both ends, deleting container deleted contents and creating container creates contents, ex. loan includes several loan items

associative classes

many to many relationship with additional fields resolved into another class(loan and item into loan item)

ERD vs class diagram

ERD: required values have dot, role names reversed(left to right), separate cardinality and participation, built in unique ID

Class: detailed multiplicity, richer semantics(right to left), navigability and visibility, include methods

lifeline sequence diagram

indicate lifetime of an object, timespan between object construction and destruction, explicit («construct») vs implicit construction, explicit(x) vs implicit destruction, vertical dashed or solid line

activation bars sequence diagrams

indicate an object is doing something, caused by incoming message and ended by a return, can be nested

messages sequence diagrams

start at lifeline-internal, end at lifeline=activate object, end at participant=create object, start/end outside system=external. can attach guard(true/false condition) where message only sent if condition is true, asterisk indicate looping(until false or to every object in collection)

public API vs private implementation

public API defines what class should do, contract, stable as possible. Private implementation defines how class behaves: don’t expose, how data is stored, can change to improve speed, reduce memory, etc.

java Collection interface

container for groups of objects(lists, sets, stacks, trees), has common behavior(add, remove, size), anything coded to work with collection will accept any collection type. public API specifies collection, private uses arrayList.

ethic conduct/misconduct

trade secrets, whistle-blowing, conflicts of interest, misrepresentation, breach of contract, bribery and fraud,

Belbin’s 9 team roles

social: resource investigator, team worker, co-ordinator. thinking: plant, monitor evaluator, specialist. action: shaper, implementer, completer finisher

bugs

imperfection where it does not meet its requirements

error

human action results in mistake

failure

event where system does not meet requirements within specified limits

fault

cause of bug

crash

a bug where the app freezes

unit testing

divide code into units for testing, consider scale of units, test units of code independently. tests should be executed frequency and automatically(CI) before committing and commits should trigger tests. should be optimized

how unit testing support software development

separation of concerns, early discovery of problems, help documentation and specification

how to isolate unit tests

use mock to test functionality of unit in isolation, does not require databse connection. Mocks a real service, returns a dummy data corresponding to dummy input. Simulate behavior of an implementation of that interface

lifecycle of tests

set up test environment, run test code, check test results, aggregate results into summary, failing tests should break CI builds

when bugs are not your fault

defective libraries, memory leakages, defective hardware, conflict between library versions, operating system bugs

when to use command line debugging

bug exists in another environment(target machine) but not on own machine

version control systems

software that tracks and manages changes to a project's files over time. ability to roll back, used for documentation, dependency(external libraries) management(clones obtain all dependencies), configuration files, configuration parameters (everyone has same setup)

good practices in version control

frequent check ins, meaningful commit messages, freeze code changes close to release data, only address critical bugs or only certain developers touch code

does CI help developers deliver functionalities quicker

CI quickens software delivery, changes that increase coverage become more frequent after CI adoption

when to model with subtypes

for conceptual modeling(model mutual exclusivity) but not for implementation(simpler code)

dealing with data history

create a many to many relationship. employee can hold many positions over time and position may be held by many employees, position history tracks it. think about current data required and what we need a historical record of

how redundancy arises

ad hoc databases(temporary for one purpose, spreadsheets), poor database design(poor analysis or ERDs), modification to existing systems

normalization

formal process of eliminating unnecessary redundancy in relations by splitting relations into smaller chunks, restructures database into semantically independent components

software architecture

is the system implemented as one piece, few/many distinct components, does it run on one machine, multiple machines or in the cloud

the ascent of information systems

monolithic/standalone, separation of components, distribution of components, cloud of billions and billions of nodes

monolithic architecture

system includes all relevant code in one executable, self-contained, no separation of responsibilities, easy to deploy, awkward to upgrade

separation of responsibilities

partition system into logically separated parts, easier to upgrade individual parts, deploy different parts in different locations, system parts more cohesive

containers and release engineering

deploy in production-like environments, efficiently store, update and distribute software and its accompanying configuration

parallel header/lines

multiple sets of line associated with the same header representing different aspects. ex. sale header has sale line w/product and shipment w/shipment line

why public and private need to be decoupled

more stable: not exposing internal implementation and can change without breaking behavior, more flexible: less coding required to switch implementations

APIs

allow code to interact with others’ applications, activate and use after applications are built, can work across on server or internet-wide, define interactions points with code, need developers to understand data model

web technologies provide convenient APIs

can access sources identified by URLs, and the HTTP protocol provides public methods that we are expected to use on the internet, specifying how data will be transferred.

Representational State Transfer (REST)

standard architecture style of building APIs, provide public behavior to API users and force barrier between developers code. Different web browsers can connect to different web servers, when you interact with a server they don’t remember you, uniform interface that codifies HTTP methods on URLs

external APIs and architecture

each microservice offer an API to interact with other microservices. Microservice actualized via containers and these containers talk to each other via their APIs

optimizing SQL DAO programming

multiple row operations, connection pools keep connections alive, reuse prepared statements, combine queries, batched requests

transactions in JDBC/Jdbi

default is auto-commit where each statement is a separate transaction, if transaction is multiple lines, disable auto-commit and manage yourself

subquery

select statement embedded inside another SQL statement