Java and Object Orientation

Java and Object Orientation

• In Java, a program's task is clarified by defining what the software should achieve, this is not how the program should operate
• Important software development phases include requirements analysis, design, implementation, and testing
• A program's actions or duties are defined through the requirements analysis
• System design details how a program will implement its requirements using UML diagrams
• Implementation involves source code in Java
• Testing guarantees a program performs as it should using JUnit frameworks
• Requirements must remain fixed in the Waterfall method. They are locked once the requirement analysis is complete, and can no longer change during design or implementation
• Classes, objects, encapsulation, inheritance, and polymorphism represent the core principles of object-oriented programming

Objects

• Objects represent real-world entities, like people, cars, tables, bank accounts, or employees
• Software objects possess state and behavior
• State is defined by variables; the number of variables can vary
• Methods define the behavior of software objects

Classes

• Classes act as blueprints, defining variables and methods shared across objects of a certain type
• A class is a blueprint for objects that will follow that form
• A class creates an object of a certain kind

Software Development Models

• Software has industrial strength and addresses a specific problem
• Expense, time constraints, and quality affect industrial software projects
• The Waterfall model organizes development in linear phases, where phases must complete before the next starts with no feedback loop
• The advantage of the Waterfall model is its simplicity which divides problems into phases
• Locking requirements early and all-or-nothing delivery are its disadvantages
• The Prototyping model mitigates risks in projects that are unfamiliar
• Prototyping addresses limitations in waterfall models by building an actual prototype
• The advantage of implementing a prototyping model is that it freezes requirements later. Also, the experience gained helps with primary development
• Potential risk of cost increases and schedule delays are its disadvantages

Iterative Model

• The iterative development model addresses key disadvantages stemming from the waterfall model such as requirements not being known or the feedback loop
• It counters the all-or-nothing drawback of the waterfall model
• The advantage of the iterative model is "get as you pay", it provides feedback for improvement
• The iterative model's architecture and design may not be optimal
• The iterative model is applicable when project risks are high with not all the requirements in place

Abstraction

• Creating independent modules is essential for large programs where monolithic structures are unreasonable
• Decomposition involves dividing programs into smaller modules that fulfill specific roles
• Abstraction is achieved through decomposition
• Decomposition aims to build separate small programs that interface in well-defined ways
• There are procedural, data and iteration abstractions, and type hierarchies

Procedural Abstraction

• Creates functions that operate with different data types
• Enables different data types and values
• Hides how code operates and just how the function operates on the data passed to it
• Focuses on what that object does rather than how
• Reusability and flexibility is promoted
• By specification states, documentation should follow terminology
• The specifications can be formal and informal
• Formal specifications have precise meaning
• Informal specifications are easier to read but are difficult to interpret precisely
• Specification language is not a programming language
• All modified inputs should be identified
• Preconditions state constraints
• Effects clauses should define behavior

Minimality

• Procedures should constrain specifications minimally
• More freedom yields more efficient implementations

Underdetermined Behavior

• Provides more than one output for certain inputs

Deterministic Implementation

• Behaves consistently when the input is called twice in a row

Generality

• Operates on larger classes of inputs

Simplicity

• Having a procedure that is easy to explain and well defined

Data Abstraction Principles

• Mutable classes allow object state changes after creation
• Immutable classes lock the state of objects once created
• Data abstraction is achieved through classes or interfaces
• This allows a class to be seen as a data type
• There are increased delays in decision making when dealing with data structures
• Data abstraction improves maintenance and during program modification
• DA hides object representation and only allows access via methods to maintain encapsulation

Data Abstraction Implementation

• Choose an object representation
• Include documentation with your design
• Use the specifications to guide the implementation of the procedures

Abstraction Function

• Captures designer intent in choosing a representation of instance variables
• It captures the correlation between instance variables and abstract objects

Representation Invariant

• It defines legal and illegal objects

Overriding clone()

• A copy is created and returned in object class
• Rules dictate clone() overriding practices
• For immutable classes implement a shallow copy and deep copy for mutable classes

Modeling with UML

• Software engineering is broader than just writing code, and includes modeling, problem-solving, knowledge acquisition and rationale management
• Abstraction can represent a system, helps visualize a system and simplify complicated systems
• Software development includes requirement analysis, design, implementation and testing
• Application and Solution Domains make up the 2SD Domain where the environment that the system will be operating and the technologies used to build the system
• Activities for problem solving include formulating, analyzing, seeking, and specifying solutions
• OO development includes requirements elicitation and analysis during object design and implementation

UML Diagrams

• UML (Unified Modeling Language) has standardized notations for object oriented methodologies
• It also is a non-proprietary standard for modeling software systems at OMG
• During the visual paradigm or use case: Include class and sequence diagrams, state charts and activity diagrams
• The Functional Model functionality is described in terms of the end user
• The object model structure of class diagrams are described based on operations
• Sequence, statechart, and activity diagrams show internal behavior
• An overall System Model includes the object and dynamic models with the functional model
• Static structures are described as classes, while associations, attributes are described through associations
• The dynamic model shows object relationships and behavior

Attributes and Operations

• Public attributes and operations are accessible to all, protected attributes and operations are accessible to subclasses
• Private attributes and operations are available within a class

Relationships

• Association lists relationships between classes
• There are inheritance (IS-A), aggregation (HAS-A), and dependency relationships
• Inheritance indicates classes derived from other classes
• Aggregation shows one class comprising instances of another with diamond heads
• Dependencies show one class utilizing the methods of another

Design Patterns

• Design patterns offers vocabulary and discussions to solve the challenges within a program
• The four essential parts of Design Pattern includes Patterns name, problem, solution, and consequences
• Structural or behavioral design patterns and creational such as a singleton
• All patterns have a unique name
• Singleton Pattern constraints class to one instance with a global access point

Composite Pattern

• Composite objects are used to manipulate primitive objects in the same way
• There children are managed within composition, and components with an abstract class

State Pattern

• State objects behavior will be modified or vary based on internal states of said object
• Each state is handled using a new class object

Observer Pattern

• Observers act independently, but need to be notified or updated whenever that subject undergoes a certain important change of state
• It also utilizes a generic structure when applying this model

Software Modeling

• Various modeling, including class, sequence, and use case diagrams

Use Case Diagrams

• Actors model entities which interact with a particular system

UML

• UML supports requirements elicitation and defines system boundaries and functionality

Use Case Elements

Name: unique description Actor: end-user and interactions Steps: functional operations Conditions: initial states Results: ending state Exceptions: handling error Special Request: non functional

Scenario-Based Requirement Elicitation

• Common scenarios for use cases include identification of actors, abstractions for possible scenarios
• Refinement of use cases, relationships among use cases

Dependency Relationships

• Relationships between use cases, they serve to reduce complexity

Use Case

• A use case encompasses a set of actions for a certain result
• A use case has actors, the specific steps, entry conditions, and a defined outcome

Testing

• Testing should supplement code and code should be tested by each path

Black Box

• Blackbox testing only examines API and specs given
• This is the first step to determine paths (such as requires or effects)

White Box

• Whitebox testing supplements blackbox testing
• Path-complete code is exercised by each code at least once

Integration Test

• Integration Test combines both system code and client applications to discover if the two interface correctly

Testing Procedures

• These procedures help find look for errors and test specs and code
• JUnit testing should use assert equals

Design Criteria

• High coupling is the goal where a single action within one component can trigger another

Cohesion

• High cohesion relates to singular focus
• The stronger the focus the well more responsibilities are well defined