Software Engineering and Object-Oriented Analysis & Design

1

Software Engineering applies systematic, disciplined, quantifiable approaches to the development, operation, and maintenance of software. Software is intangible, does not wear out, and is complex — it degrades through lack of maintenance rather than physical wear.

2

Software Process Models (SDLC): Waterfall — sequential phases (Requirements→Design→Implementation→Testing→Maintenance). Simple but rigid; changes are expensive once a phase is complete. V-Model — each development phase is paired with a testing phase on the opposite side of the V (Requirements↔Acceptance Test, Design↔Integration Test). Spiral — risk-driven, iterative; each cycle: plan→risk analysis→prototype→evaluate. Agile — iterative and incremental; working software over documentation, customer collaboration, responding to change. Prototype — builds an early working model to clarify requirements. Big Bang — no structured process (for very small/experimental projects).

3

Functional Requirements define what the system should do — specific behaviour, calculations, outputs, and services (e.g., 'The system shall authenticate users by username and password'). Non-Functional Requirements define how the system should perform — quality attributes: performance (response time, throughput), security, reliability, scalability, usability, maintainability.

4

SRS (Software Requirements Specification) — a formal document that completely describes what a software system should do. It is the basis for design, testing, and validation. Must be complete, consistent, correct, and unambiguous.

5

Requirements Engineering Process: Elicitation (gather requirements from stakeholders via interviews, observation, surveys — first step) → Analysis (refine, resolve conflicts, detect ambiguities) → Specification (document in SRS) → Validation (check requirements are correct, complete, and testable) → Management (track changes throughout the lifecycle).

6

Agile Principles (Agile Manifesto, 2001): Individuals and interactions over processes and tools. Working software over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change over following a plan. Scrum is the most popular Agile framework — iterative sprints (2–4 weeks), daily standups, Sprint Review, Sprint Retrospective.

7

Feasibility Study — determines if the project is technically, economically, legally, and operationally feasible before committing resources. Project Planning — defines scope, schedule, resources, risk, and deliverables.

8

Software Myths — incorrect beliefs about software: e.g., 'adding more developers to a late project makes it later' (Brooks's Law). Software does not wear out physically, but it becomes difficult to maintain over time.

1

Software Design translates requirements into a blueprint for the software. Good design aims for high cohesion and low coupling — independently understandable, maintainable, and testable modules.

2

Cohesion — measures how strongly related the responsibilities within a single module are. Higher is better. Types (best to worst): Functional (module performs exactly one well-defined task — best) → Sequential → Communicational → Procedural → Temporal → Logical → Coincidental (unrelated tasks grouped randomly — worst).

3

Coupling — measures the degree of interdependence between modules. Lower is better. Types (best to worst): Data coupling (modules share only simple data parameters — best) → Stamp coupling → Control coupling → External coupling → Common coupling → Content coupling (module directly modifies another's internals — worst).

4

Design Principles: Abstraction — hide complexity by exposing only essential details. Modularity — divide software into smaller, manageable, independent units. Refinement (Stepwise) — progressively elaborate from abstract to detailed design. Information Hiding — encapsulate module internals so changes don't propagate to other modules (Parnas principle).

5

Software Architecture defines the high-level structure of a system. Common patterns: Client-Server — clients request services from a central server. Layered — software organised in layers (e.g., Presentation→Business Logic→Data). Distributed Object (e.g., CORBA) — objects distributed across network. Repository / Data-Centred — all components interact through a shared data store.

6

Component-Based Software Engineering (CBSE) — building systems by composing pre-built, reusable components. Promotes reuse, reduces development time. Components have well-defined interfaces and can be from third parties.

7

Design Patterns — proven, reusable solutions to recurring design problems. Creational (Singleton, Factory, Builder), Structural (Adapter, Decorator, Facade), Behavioural (Observer, Strategy, Command). Originally codified by the 'Gang of Four' (GoF).

8

Object-Oriented Design Principles: Encapsulation — bundle data and methods, hide internals. Inheritance — reuse parent class behaviour. Polymorphism — same interface, different implementations. Abstraction — model only relevant aspects.

1

Software Testing verifies that software meets requirements and works correctly. Testing cannot prove the absence of bugs — it can only reveal their presence. Test case = input + expected output + execution conditions.

2

Testing Levels: Unit Testing — tests individual modules/functions in isolation (done by developers). Integration Testing — tests interactions between combined modules (interfaces, data flow). System Testing — tests the complete system against requirements. Acceptance Testing — validates with end users whether the system meets their needs (UAT).

3

White-Box Testing (Glass-box / Structural testing) — tester knows the internal code structure. Designs tests based on code paths, branches, loops. Techniques: statement coverage, branch coverage, path coverage. Done by developers. Black-Box Testing — tester has no knowledge of internals. Tests based on specifications and requirements only. Techniques: equivalence partitioning, boundary value analysis.

4

Verification vs Validation (V&V): Verification — 'Are we building the product RIGHT?'. Reviews, inspections, walkthroughs — checks against specifications. Validation — 'Are we building the RIGHT product?'. Testing with real users — checks against actual needs.

5

COCOMO (Constructive Cost Model) — estimates software project effort, cost, and duration based on Lines of Code (LOC). Three models: Basic, Intermediate (also considers cost drivers), Detailed (work breakdown). Formula: Effort = a × (KLOC)^b person-months.

6

CMMI (Capability Maturity Model Integration) — a framework for improving software development processes. Five maturity levels: Level 1 Initial (chaotic, ad hoc), Level 2 Managed (projects planned and tracked), Level 3 Defined (standard processes org-wide), Level 4 Quantitatively Managed (metrics-driven), Level 5 Optimizing (continuous improvement).

7

ISO 9001 — an international quality management standard. Provides guidelines for consistent processes, customer satisfaction, continual improvement. ISO 9001 certification signals that an organization meets international quality standards.

8

SCM (Software Configuration Management) — controls changes to software artifacts throughout the lifecycle. Activities: Change control (formal process for approving changes), Version control (tracking code revisions — Git), Release management (packaging and deploying software versions). Prevents uncoordinated changes from causing defects.

9

Alpha Testing — performed by internal developers/testers at the developer's site before release. Beta Testing — performed by a limited group of real external users in their own environment before the final release.

1

Object-Oriented (OO) Paradigm models software as a collection of interacting objects, each combining data (attributes) and behaviour (methods). Core OO concepts: Encapsulation (data + methods bundled, internals hidden), Inheritance (IS-A relationship, child reuses parent), Polymorphism (same interface, different forms), Abstraction (expose essentials, hide complexity).

2

UML (Unified Modeling Language) — a standardised graphical language for visualising, specifying, constructing, and documenting software systems. Created by Booch, Rumbaugh, and Jacobson (Rational Software, 1994–1997). Not a programming language — it's a modelling notation.

3

UML Diagram Categories: Structural diagrams — model the static structure: Class diagram (classes, attributes, methods, relationships), Object diagram (instances at a point in time), Component diagram (physical components), Deployment diagram (hardware/software nodes). Behavioural diagrams — model dynamic behaviour: Use Case diagram, Sequence diagram, Collaboration/Communication diagram, Activity diagram (workflow/flowchart), State diagram (state transitions).

4

Use Case Diagram — shows what the system does from the user's perspective. Elements: Actor (external entity interacting with the system — person, device, or another system), Use Case (a specific function/service the system provides), System boundary (defines scope), Relationships (include, extend, generalize).

5

OO Relationships: Generalization (IS-A) — inheritance relationship (Dog IS-A Animal). Association — general 'uses' relationship between classes. Aggregation (HAS-A, weak) — whole–part where part can exist independently (University HAS-A Department). Composition (HAS-A, strong) — whole–part where part cannot exist without the whole (House HAS-A Room). Dependency — one class uses another temporarily.

6

Class Diagram — the most widely used structural UML diagram. Shows: class name, attributes (data members), operations (methods), and relationships (associations, generalization, aggregation, composition). Multiplicity specifies how many objects participate in a relationship (1, 0..*, 1..*).

7

OO Analysis (OOA) — the analysis phase focuses on WHAT the problem is. Identifies objects, classes, attributes, methods, and relationships from the problem domain. Does NOT specify how they will be implemented. OO Design (OOD) — translates the analysis into a blueprint HOW the system will be built.

8

OO Development Cycle: Requirements Gathering → OO Analysis (identify objects) → OO Design (design classes/interactions) → Implementation (code classes) → Testing → Maintenance.

1

OO Analysis vs OO Design: Analysis focuses on WHAT the problem is — understanding and modelling the real world. Design focuses on HOW to solve it — defining classes, their responsibilities, and interactions in software terms. Design elaborates the analysis model into an implementable blueprint.

2

Design Class Diagram — extends the analysis class diagram with implementation details: visibility symbols (+/-/#), data types for attributes, method signatures, constructor/destructor, navigation arrows, and dependency relationships. It is the primary design artifact for a class-based language.

3

Interaction Diagrams — model how objects communicate to fulfil a use case. There are two types: Sequence diagram — emphasises time ordering of messages (vertical time axis, objects on horizontal). Collaboration / Communication diagram — emphasises the structural organisation of objects and their links (numbered messages showing sequence). Both show the same information — you can convert one to the other.

4

Sequence Diagram Elements: lifeline (named object), activation bar (period of activity), message (solid arrow — call), return (dashed arrow), self-message, destruction marker (X). Time flows top to bottom.

5

Design Patterns — proven, reusable solutions to common OO design problems (GoF — Gang of Four). Singleton — ensures only one instance of a class exists (global access point). Factory Method — defines interface for creating objects, but lets subclasses decide which class to instantiate. Observer — one object (subject) notifies multiple dependents (observers) when its state changes. Strategy — defines a family of algorithms; client selects which to use at runtime.

6

Visibility Modifiers in UML: + = public (accessible by all). - = private (accessible only within the class). # = protected (accessible within the class and its subclasses). ~ = package (accessible within the same package).

7

GRASP Principles (General Responsibility Assignment Software Patterns) — guidelines for assigning responsibilities to classes: Creator (who creates an object?), Information Expert (assign responsibility to the class with the most relevant information), Controller (handles system events), Low Coupling, High Cohesion, Polymorphism, Indirection, Pure Fabrication, Protected Variations.

8

System Sequence Diagram (SSD) — a simplified sequence diagram showing interactions between external actors and the system as a black box. Documents system events for a use case scenario.

1

Mapping Design to Implementation — translating OO design artifacts (class diagrams, sequence/collaboration diagrams) into actual programming language code. The design class diagram acts as the primary blueprint for implementation.

2

Design Class Diagram → Code: Attributes → fields / instance variables in the class. Operations / Methods → method definitions with appropriate signatures. Constructor → initialises the object's state when instantiated. Associations → reference attributes (one class holds a reference to another). Visibility modifiers (+/-/#) → public/private/protected access modifiers in code.

3

Interaction Diagrams → Method Bodies: Each message in a collaboration or sequence diagram becomes a method call in the receiver object's method body. The sequence of messages defines the control flow within a method. This is the primary technique for deriving method logic from design.

4

Associations → Reference Attributes: A uni-directional association from Class A to Class B means Class A has an attribute of type Class B (a reference). Multiplicity determines whether it's a single reference or a collection (array, list). 1 = single reference. * = collection.

5

Exception Handling — a mechanism to handle runtime errors gracefully without crashing. Keywords: try (code that might throw), catch (handles specific exception types), throw (signals/raises an exception), finally (always executes — cleanup). Good OO design separates normal flow from error handling.

6

Engineering Directions: Forward Engineering — the traditional direction: go from design (model) → source code. Reverse Engineering — go from existing source code → model (recover design from code, useful for legacy systems). Round-Trip Engineering — keeps model and code in sync automatically; changes in either direction are propagated to the other.

7

Persistent Objects — objects whose state must survive beyond the execution of the program (persisted to a database or file). ORM (Object-Relational Mapping) maps OO classes to relational database tables automatically (e.g., Hibernate, Entity Framework, Django ORM).

8

Refactoring — improving the internal structure of existing code without changing its external behaviour. Makes code cleaner, more maintainable, and easier to extend. Common refactorings: extract method, rename, move method, replace magic number with constant.

9

Code Generation — CASE (Computer-Aided Software Engineering) tools can automatically generate code skeletons from UML design diagrams, speeding up the mapping from design to implementation.