Software Life Cycle – Planning, Analysis, Design, Implementation, Testing and Integration, Maintenance

Quality – Usability, Efficiency, Reliability, Maintainability, Reusability

Waterfall – Requirements, Design, Implementation, Verification, Maintenance

Types of Projects – Greenfield, Evolutionary/Maintenance: Corrective, Adaptive, Enhancement, Reengineering

Abstraction – Representing real life things as objects, attributes as instance variables, etc.

Modularity – Code divided into classes, classes into method

Encapsulation – Details made private, information hiding

Contract – Formal, precise, verifiable interface specifications for software components

Interface – Like abstract class but without executable statements, class can implement multiple

Polymorphism – Abstract operation may be performed in different ways by different classes, methods must have same name

Dynamic Binding – Occurs when variable has superclass as type, more than one polymorphic method that could be run among type variable
and subclasses, decision made at run time not compile time

Instance vs Class – Something is class if it could have instances, instance if it is single member of a set defined by class

Casting – If variable v declared to have type X, you can only invoke operations defined in X or superclasses, even though instance of subclass
of X may be stored in variable. If you know subclass is stored, you can cast to subclass to perform operation.

Abstract Class – Operation should be declared highest in hierarchy where it makes sense, if lacking implementation at that level it must be
abstract. No instances of abstract classes can be created. If superclass has abstract operation, subclasses must implement.

Framework – Reusable software that implements generic solution to generalized problem. Intrinsically incomplete. Missing classes/methods
are slots, optional functionality is hooks. Horizontal framework – general application facilities that many programs can use. Vertical - more
complete but some slots to adapt to specific program needs.

Library – Framework composed of library of classes. API is set of all public methods of these classes.

Product Line – Set of products built on common base of technology, software common to all products is included in framework, product
produced by filling hooks and slots.

Client-server – Separate programs for client and server. Server – Initializes, listens, handles events from client, may stop, must terminate
cleanly. Client – Initializes itself, initiates connection, sends messages, handles events from server, must terminate cleanly

TCP – Handles connections between two computers, computer then exchange IP messages, assures that messages have been received

Sockets and OCSF – OCSF has 3 abstract classes, AbstractClient – Must be subclassed and create implementation of
handleMessageFromServer(), AbstractServer – Must be subclassed and implement handleMessageFromClient(), ConnectionToClient –
sendToClient(), close()

IP – Routes messages from one computer to another

Protocol – The messages the client sends to the server form language, server needs to be programmed to understand. Vice versa. These two
languages and rules of conversation form protocol.

Requirements:

Functional: what system should do, Quality: constraints on design to meet specified benchmarks, Platform: constraints on environment and
technology of system, Process: constraints on plan and development methods.

Good Requirement – Identifies system under discussion and desired end result that is wanted within specified time that is measurable

“The Online Banking system shall allow the Internet user to access her current account balance in less than 5 seconds.”

System under discussion correct identifier (shall) defined end result quality criteria
Each requirement must form complete sentence, contain subject and predicate.

Subject: user type or system under discussion, Predicate: condition, action, or intended result, Verb in predicate: “shall/will/must” for
mandatory, “may/would” for optional.

Whole requirement provides specifics of desired end goal or result, contains success criterion or measurable indication of quality

Avoid speculation, suggestions or possibilities, wishful thinking, vague undefinable terms

Use-cases: typical sequence of actions user performs to complete intended task

Use-case should: Cover sequence of steps, describe user interaction with system, be as independent as possible from any particular UI
design, only include actions in which actor interacts with computer, not manually

How to describe single use case: Name, Actors, Goals, Preconditions, Summary, Related Use Cases, Steps (two columns), Postconditions

Extensions: Used to make optional interactions explicit or handle exceptional cases.

Generalizations: Much like superclass in class diagram, represents several similar use cases

Inclusions: Allow one to express commonality between different use cases, included in other use cases, even very different use cases can
share sequence of actions, enable you to avoid repeating details in multiple use cases

Attributes – Simple data found in classes and instances

Associations – Linkages between classes

System model vs Domain model: System domain model omits many classes needed to build complete system, complete system model
includes system domain model, user interface classes, architectural classes, utility classes

Reflexive associations – class associates with itself

Association classes – sometimes attribute that concerns two associated classes cannot be placed in either class, ends up in middle, ex:

Aggregation: represents part-whole relationship, like 1 vehicle to many vehicle parts, can be done if parts are part of aggregate, aggregate
composed of parts, and when someone controls aggregate, they control parts, represented by open diamond

Composition: strong kind of aggregation, if aggregate destroyed then parts are destroyed as well, represented by closed diamond

Operations: represent abstract functions performed by classes and instances, as well as specific methods implementing these

Directionality: Associations by default bi-directional, can be made uni-directional with arrow