Object-Oriented Analysis & Design and Unified Process: Key Concepts from Lecture Notes

Lifecycle Methodologies and Evolution

• Purpose of methodologies: provide a formalized approach to implementing the system development lifecycle (SDLC) to avoid ad-hoc, rushed, or unplanned development.

• Two broad categorizations of methodologies by focus:

  • Data-centered: focus on how data is stored (schemas) and the data-handling processes that modify data.

  • Process-centered: focus on the workflows and processes that operate on data.

  • Object-oriented: blends data and processes into the same conceptual unit (objects).

• Sandwich analogy (from the book): processes operate on data and rely on data storage locations to function; data must be stored somewhere to support processes.

• Evolution by sequencing: structural design → rapid application development (RAD) → Agile development.

• Early, middle, and late stages:

  • Waterfall (traditional): plan → analyze → design → implement → test → deploy; each phase must complete before the next begins.

  • Parallel development: divide the project after analysis/design so sub-projects proceed in parallel and integrate later.

  • Rapid development: deliver core functionality early as a version, collect feedback, and iterate toward second/third versions.

  • Prototyping: build a prototype to gather feedback; throw away or reuse prototypes; can be throwaway prototyping for speed.

  • Agile development: short iterations (planning, analysis, design) with early, partial functionality in the system; hardware/software advances enable faster feedback loops and customer involvement.

• Extreme Programming (XP): late 1990s–early 2000s; team-based development with paired programming to catch mistakes in real time.

• Scrum: rugby metaphor; work in sprints; prioritize next achievable increment; deliver working product after each sprint.

• Object-oriented methodologies enabled by hardware/software advances: data and processes can be modeled together; OO design supports reuse and incremental delivery.

• Historical progression: from structured/functional methodologies to OO, Unified Process (UP), and finally UML as the modeling standard.

• Practical takeaway: choice of methodology depends on project characteristics (requirements, reliability, risk, team, and environment). Waterfall remains useful for very large or well-understood projects; Agile/UP/OOAD are common in modern practice.

Object-Oriented Analysis and Design (OOAD) Essentials

• Core idea: unify data and processing by focusing on objects that encapsulate both data (attributes) and behavior (methods).

• Key concepts:

  • Object: a specific instance with state (data) and behavior (methods).

  • Class: a template that defines a group of objects with common attributes and methods.

  • Attributes: information describing an object/class (e.g., patient name, address, phone).

  • Methods: behaviors an object can perform (e.g., make an appointment, calculate last visit).

  • State: description of an object's values at a given time (e.g., patient status: admitted, discharged, re-admitted).

  • Message: a trigger to invoke a method on an object (e.g., create message to a patient class to create a new patient).

• Example (healthcare domain):

  • Class: Patient

  • Attributes: name, address, phone, insurance, status, dateofbirth

  • Methods: createAppointment(), getLastVisit(), changeStatus()

  • States for a patient: Admitted → Discharged → Re-admitted (illustrating state over time)

• Encapsulation: data and processes are bundled into a single entity (the object).

• Information hiding: internal implementation details are hidden; external actors interact via well-defined inputs/outputs (objects act as black boxes).

• Inheritance: classes can derive from superclasses; helps share common attributes/methods (e.g., Person superclass with common attributes like name, address; Doctor and Patient inherit from Person).

  • Superclass: a general class (e.g., Person) that provides common attributes/methods.

  • Subclass: a more specialized class (e.g., Doctor, Patient) that inherits from the superclass.

  • Concrete classes: can have instances (e.g., Patient, Doctor).

  • Abstract classes: used as templates; do not have their own instances (e.g., Person as an abstract superclass).

• Polymorphism: same message (method call) can produce different results depending on the object receiving it (e.g., draw() on different shapes).

• Dynamic binding: runtime determination of an object’s type to enable polymorphism; binding occurs at runtime so different objects can respond differently to the same message.

• Object-oriented objectives and views:

  • Use-case driven: start from user scenarios and use cases.

  • Architecture-centric: consider the software architecture (static structure, dynamic behavior, and functional aspects).

  • Iterative and incremental: refine models layer by layer and deliver in increments.

  • Three views of architecture: functional/behavioral (what it does), static structure (how it’s organized), dynamic behavior (how it responds to messages).

• Use-case focus in OOAD: begin with user roles and use cases to define system behavior; map to objects and interactions.

• Historical motivation: OOAD emerged to address complexity by encapsulating data and processes and by enabling reuse and easier maintenance.

Unified Process (UP) and Unified Modeling Language (UML)

• Unified Process (UP): an object-oriented, iterative, and incremental software development process that standardizes OOAD practices.

• Four phases (temporal) of UP:

  • Inception: feasibility analysis; define project scope; identify stakeholders; assess business value and risks.

  • Elaboration: analyze requirements; establish the baseline architecture; model requirements with UML; begin risk mitigation.

  • Construction: actual development; implement design; iterative prototyping and refinement; incremental product delivery.

  • Transition: deployment; testing; user feedback; final adjustments before production release.

• Workflows in UP:

  • Engineering workflows: Business Modeling, Requirements, Analysis & Design, Implementation, Testing, Deployment.

  • Supporting Workflows: Configuration and Change Management, Project Management, Environment.

• UP is iterative and overlapping: multiple workflows run in parallel across phases; focus areas shift as the project evolves.

• Extended UP (and beyond): refinements to workflows and the inclusion of production-oriented activities; some areas like staffing, budgeting, and contract management can be less explicitly covered in the core UP/extended UP models.

• Unified Modeling Language (UML): a standardized set of diagrams to model OOAD artifacts; around 15 standard diagrams in UML 2.x, categorized into two broad groups:

  • Structure diagrams: show the static structure of the software (e.g., Class Diagram, Object Diagram, Component Diagram, Deployment Diagram).

  • Behavior diagrams: show dynamic behavior (e.g., Use Case Diagram, Sequence Diagram, Activity Diagram, State Diagram).

• OOAD characteristics in UP/UML:

  • Use-case driven: model user goals and interactions via use cases and actors.

  • Architecture-centric: define software architecture across views (function, structure, behavior).

  • Iterative and incremental: deliver progressively, refine requirements, and expand the system over time.

• Practical note: the UP/OOAD approach maps well to iterative development and to aligning software architecture with evolving requirements.

Core OOAD Concepts: Encapsulation, Inheritance, Polymorphism, and More

• Encapsulation: combine data and behavior into a single object; restrict access to internal details to promote reusability and reduce coupling.

• Information hiding: outside modules interact with an object via its defined inputs/outputs; internal implementation is hidden (black-box concept).

• Inheritance: enables reuse and organization of related classes; superclass defines common attributes/methods; subclasses extend/ specialize behavior.

  • Concrete vs abstract classes: concrete classes can be instantiated; abstract classes serve as templates and cannot be instantiated.

• Polymorphism: the same message can be handled by different object types with appropriate responses; enables flexible interfaces.

• Dynamic binding: method resolution happens at runtime, enabling polymorphic behavior.

• OOAD advantages: promotes reuse, modularity, maintainability, and alignment with real-world entities.

Object-Oriented Use-Case Language and Architectural Views

• Use-case driven development begins with actor roles and use-case descriptions (e.g., physicians, nurses, administrators in an electronic health record system).

• Architecture-centric design emphasizes three views:

  • Functional/Architectural view: what the system should do for users (functional requirements).

  • Static view: structure (classes, attributes, relationships, interfaces).

  • Behavioral view: how the system responds to messages, the sequencing of operations, and the interactions between objects.

• Encountered characteristics:

  • Iterative refinement: models improve as requirements become clearer.

  • Reuse: modular design with reusable components across use cases.

The Unified Process: Phases, Workflows, and Diagrams

• Phases overview:

  • Inception: feasibility, business modeling, initial requirements gathering, project scope, stakeholder identification.

  • Elaboration: risk assessment, comprehensive requirements modeling, architecture baseline, major design decisions.

  • Construction: iterative development and integration, production-ready increments.

  • Transition: final testing, deployment, and user training.

• Workflows:

  • Engineering workflows (core activities): business modeling, requirements, analysis & design, implementation, testing, deployment.

  • Supporting workflows: configuration & change management, project management, environment.

• The UP modeling framework relies on UML to express analysis and design artifacts across the workflows.

• The UP’s emphasis on iterative and incremental delivery aligns with Agile sensibilities and modern SDLC practices.

Object-Oriented Requirements, Use Case Points (UUCP)

• Use-case points (UCP) methodology provides a quantitative estimate of effort based on requirements expressed as use cases and actors.

• Step-by-step overview:

  • Step 1: Determine actors grouped as Simple, Average, and Complex.

  • Example weights (typical in UCP methods): Simple Actor = 1, Average Actor = 2, Complex Actor = 3 (illustrative; actual weights may vary by methodology).

  • Step 2: Determine use cases grouped as Simple, Average, and Complex.

  • Example weights (typical): Simple Use Case = 5, Average Use Case = 10, Complex Use Case = 15 (illustrative).

  • UUCP = UAW + UUCW, where UAW = sum of actor weights and UUCW = sum of use-case weights.

  • Step 3: Compute Technical Complexity Factor (TCF) and Environmental Factor (EF):

  • TCF is derived from 13 technical factors Fi with weights Ci:
    ext{TCF} = 0.6 + 0.01 imes igg(

    

    )

    ),
    where Fi is the rating for factor i (0–5) and Ci is the factor’s weight.

  • EF is computed from 12–14 environmental factors with weights (typical):
    ext{EF} = 1.4 + (-0.03) imes igg(

    

    )

    ,
    where Ei is the rating (0–5) and Fi is the factor’s weight.

  • Step 4: Adjusted Use Case Points (UCP) = UUCP d7 TCF d7 EF.

  • Step 5: Convert to effort (person-hours or person-months):

  • Effort (PHM) = UCP d7 PHM, where PHM (Person Hours Multiplier) is either 20 or 28 depending on environment/factors.

  • Step 6: Use case points provide a basis to estimate effort; examples in the course use book figures.

• Practical note: Use Case Points connect requirements to effort estimates and emphasize the alignment of use cases with system behavior.

Economic Feasibility, Financial Metrics, and Risk Analysis

• Purpose of feasibility analyses: assess technical, economic (financial), and organizational risks/feasibility before committing to a project.

• Three feasibility domains:

  • Technical feasibility: can we technically build or acquire and support the system? Do we have the right people, skills, and interoperability with existing systems?

  • Economic feasibility: do the expected benefits justify costs? Tangible vs intangible benefits; one-time development costs vs ongoing operational costs.

  • Organizational feasibility: will stakeholders actually use the system? Does the project align with organizational goals and strategic direction?

• Steps in economic feasibility analysis:

  • Identify all costs and benefits (tangible and intangible).

  • Value each item (economic valuation) and consider cash flows over time (years).

  • Compute Present Value (PV) for each cost and benefit:
    $ext{PV} = rac{V}{(1 + r)^t}$
    where V = value in year t, r = annual discount/interest rate, t = number of years.

  • Compute Net Present Value (NPV):
    $ext{NPV} = ext{PV(Benefits)} - ext{PV(Costs)}$

  • Compute Return on Investment (ROI):

  • In the course materials, ROI is presented as
    $ext{ROI} = rac{ ext{NPV}}{ ext{PV(Costs)}}$
    (alternative common definition: ROI = (Total Benefits − Total Costs) / Total Costs).

  • Break-even analysis: identify when cumulative NPV becomes non-negative; the year when benefits catch costs.

  • The course illustrates a stepwise approach with a concrete example: break-even appears after the end of year 3 or in year 4 depending on values.

  • Conceptual method described in the transcript:

    • Let NPVy be the yearly net present value for year y and Ccum{y-1} be the cumulative NPV up to year y-1.

    • The fraction of year to break-even within year y is
      $f = - rac{Ccum<em>{y-1}}{ ext{NPV}</em>y} ext{ (assuming } ext{NPV}_y > 0 ext{)}.$

    • Break-even time within year y is approximately
      $ext{Break-even time} \, ext{≈} \, (y-1) + f.$

    • The transcript example shows break-even crossing in year 4 (i.e., after year 3) for a particular set of numbers.

• Practical interpretation: benefits often accrue later; initial costs are higher; discounting reduces value of later benefits; thus, many IT projects have a multi-year payback horizon.

Risk, Case Studies, and Stakeholders

• Stakeholders in feasibility and project approval:

  • Project sponsor, organizational management, system users.

  • The approval committee reviews system requests and feasibility analyses before green-lighting a project.

• Purpose of portfolio management: manage multiple IT projects as a portfolio to align with organizational goals and maximize value:

  • Categorize projects by size, cost, risk, value, and strategic alignment.

  • Prioritize and adjust project order within the portfolio to optimize organizational outcomes.

  • Avoid ad hoc prioritization (e.g., based solely on sponsor seniority).

• Organizational alignment: ensure project goals map to the organization’s vision/mission and strategic goals.

• Common risk considerations in technical feasibility:

  • Familiarity with business workflows; familiarity with the technology; project size; personnel types; interoperability with existing systems.

• Common risk considerations in economic feasibility:

  • Costs (one-time development, ongoing operational costs) vs benefits (tangible and intangible); timing of benefits.

• Common risk considerations in organizational feasibility:

  • Will stakeholders actually use the system? Will training and adoption occur as intended?

Planning, Scheduling, and Project Management Tools

• Work Breakdown Structure (WBS):

  • A hierarchical list of tasks required to complete the project.

  • Includes subtasks, durations, and dependencies; used to scope the project and plan resources.

• Gantt chart:

  • Visual timeline showing start/end dates for tasks, durations, progress bars, dependencies, milestones, and owners.

  • Helpful to see if a project is ahead/behind schedule relative to today (often indicated by a vertical today line).

  • Best practice: limit to 20–30 tasks to maintain readability; use subtasks if needed but not to overwhelm the chart.

• Network diagram (flowchart of tasks):

  • Boxes for tasks with a task ID, duration, start/end times, and arrows showing sequencing.

  • Completed tasks cross-marked; in-progress tasks highlighted; used to visualize dependencies.

• Program Evaluation and Review Technique (PERT):

  • Handles uncertainty in task duration with three estimates: Optimistic (O), Most Likely (M), Pessimistic (P).

  • PERT estimate can be computed as a weighted average to get a more robust duration estimate for uncertain tasks.

• Critical Path Method (CPM):

  • Identify the longest path through the network diagram; this path determines the minimum project duration.

  • Tasks on the critical path are those with no slack; these tasks are most crucial to keep on schedule.

• Timeboxing and Agile sprint planning:

  • Timeboxing: set a fixed time period (e.g., a sprint) and define goals to be achieved within that window; new requirements are deferred to future periods.

  • In Agile, sprints are timeboxed iterations designed to deliver a working product increment.

• Trade-offs in estimation:

  • Adding functionality vs time and cost: more functionality typically increases time and cost; reducing time often sacrifices functionality or requires more resources.

• Use-case point estimation workflow (summarized):

  • Identify actors and use cases (and their complexities) to compute UUCP.

  • Calculate technical and environmental factors to obtain TCF and EF.

  • Compute adjusted Use Case Points: UCP = UUCP d7 TCF d7 EF.

  • Multiply by a person-hours multiplier (PHM) to get estimated effort in hours:
    $ext{Effort (hours)} = ext{UCP} d7 ext{PHM}, ext{ where PHM } ext{is } 20 ext{ or } 28.$

• Use-case vs Agile stories: Use-case points relate to larger use-case groupings; Agile stories can be aligned to use cases or treated as smaller deliverables within sprints.

Staffing, Teams, and Organizational Environment

• Staffing considerations:

  • Determine how many people are needed to execute tasks; match skills to activities.

  • Understand that effort in person-hours does not translate linearly to calendar time; dynamics of coordination affect throughput.

  • Concept of person-months vs person-hours: e.g., 60 person-months could be allocated as 10 people for 6 months or other configurations; not strictly linear due to coordination overhead.

• Gel team concept: highly cohesive, cross-functional teams with strong ownership and collaboration; members understand each other’s strengths/weaknesses; shared identity and accountability.

• Motivation techniques:

  • 20% time rule: allow engineers to spend a portion of time (e.g., 20%) on self-directed projects that may benefit the overall effort; fosters creativity and motivation.

  • Balancing autonomy and alignment with project goals to avoid misalignment and conflict.

• Conflict management: strategies to minimize and resolve conflicts within teams; emphasis on clear roles, open communication, and shared objectives.

• Staffing plan outputs: number of people per activity, roles, motivation approaches, and conflict management strategies.

Environment, Standards, and Tools

• Environment and infrastructure management:

  • Selecting the right CASE (Computer-Aided Software Engineering) tools to manage documentation, diagrams, and artifacts throughout the lifecycle.

  • Use of environment standards: naming conventions, standardized forms, and consistent documentation practices to reduce complexity.

• Documentation importance: ensure ongoing documentation to support future maintenance; poor documentation leads to knowledge loss when team members change.

• Tools and platforms mentioned:

  • CASE tools and environments (e.g., project management modules alongside CASE capabilities).

  • The organization’s project environment supports modeling with UML diagrams and related artifacts.

Practical Examples and Real-World Relevance

• Government/large-scale projects (illustrative caution):

  • Large public-facing websites (e.g., government portals) have faced performance and testing challenges when not following rigorous testing and performance assessment; Agile/UP practices aim to mitigate such risks by iterative testing and incremental delivery.

• Healthcare example (Use-case focus):

  • Electronic Health Record (EHR) systems involve multiple user roles (physician, nurse, administrator) with distinct use cases (e.g., note creation, patient lookup, documentation sharing).

• Data vs process vs object focus example:

  • Sandwich example illustrates how data storage (condensation) and processes (sandwich-making steps) interact; OOAD seeks to unify these into objects that carry both data and behavior.

Quick Reference: Key Formulas and Concepts

• Present Value:
  $ext{PV} = rac{V}{(1 + r)^t}$
  where V = value in year t, r = annual discount rate, t = number of years.

• Net Present Value (NPV):
  $ext{NPV} = ext{PV(Benefits)} - ext{PV(Costs)}$

• Return on Investment (ROI):

  • Formula presented in the course:
    $ext{ROI} = rac{ ext{NPV}}{ ext{PV(Costs)}}$

  • Common alternative:
    $ext{ROI} = rac{ ext{Total Benefits} - ext{Total Costs}}{ ext{Total Costs}}$

• Break-even within a year (concept and approach):

  • Break-even occurs when cumulative NPV crosses from negative to non-negative.

  • Within-year calculation (illustrative):
    f = - rac{Ccum{y-1}}{ ext{NPV}y} \
    ext{Break-even time} \, ext{≈} \, (y-1) + f

  • Example interpretation: break-even might occur after the end of year 3 or during year 4 depending on NPV_y and cumulative values.

• Use Case Points (UUCP, UCP):

  • Unadjusted Use Case Points:
    $ext{UUCP} = ext{UAW} + ext{UUCW}$

  • Actor weights (typical): Simple = 1, Average = 2, Complex = 3

  • Use Case weights (typical): Simple = 5, Average = 10, Complex = 15

  • Unadjusted Use Case Points (UUCP):
    $ext{UUCP} = ext{(sum of actor weights)} + ext{(sum of use-case weights)}$

  • Technical Complexity Factor (TCF):
    $ext{TCF} = 0.6 + 0.01 imes \bigg( ext{Sum of } F<em>i imes C</em>i \bigg)$
    where Fi are factor ratings (0–5) and Ci are their weights.

  • Environmental Factor (EF):
    $ext{EF} = 1.4 + (-0.03) imes \bigg( ext{Sum of } E<em>j imes D</em>j \bigg)$
    where Ej are environmental ratings (0–5) and Dj are weights.

  • Adjusted Use Case Points:
    $ext{UCP} = ext{UUCP} imes ext{TCF} imes ext{EF}$

  • Effort (person-hours):
    ext{Effort (hours)} = ext{UCP} imes ext{PHM}, \
    ext{PHM} \, ext{(Person Hours Multiplier)} \in {20, 28}

• Project planning and estimation: use WBS, Gantt charts, PERT, CPM, and network diagrams to plan, schedule, monitor progress, and identify critical tasks.

• Scope management: timeboxing to prevent scope creep; prioritize requirements; early freeze on initial scope; add nice-to-haves in later iterations or versions.

• Team dynamics and governance:

  • Gel team concepts: high cohesion, ownership, and identity; strong collaboration improves outcomes.

  • Stakeholder involvement: ensure alignment with organizational goals; gather input from project sponsor, management, and end-users.

Summary Takeaways

• Modern SDLC practice emphasizes object orientation, iterative development, and a structured process (UP/UML) to manage complexity and facilitate reuse.

• OOAD integrates data and behavior into reusable objects; encapsulation, information hiding, inheritance, and polymorphism underpin modular, maintainable designs.

• UP and UML provide a practical framework for modeling, analysis, design, implementation, testing, and deployment with iterative improvements and well-defined views.

• Economic feasibility, including NPV, ROI, and break-even analysis, helps justify IT investments and guides portfolio-level prioritization.

• A disciplined approach to planning (WBS, Gantt, Network diagrams, PERT/CPM) and disciplined management of scope (timeboxing) help deliver reliable, timely software in real-world environments.

• Stakeholder alignment, effective staffing, and a well-chosen toolset (CASE/UML) are essential to translating requirements into successful software systems.