Unified Process Model and UML

4.1 Why Object-Oriented Development Needs Iteration

4.1.1 The Core Problem: Requirements That Refuse to Stay Still

For small projects, planning lives in your head and the requirements are clear. The main challenge starts when requirements are not clear — and, worse, when they keep changing. That is the central reason we need an iterative software development process — a process that builds the system as a series of mini projects, each cycle a small repeat of the whole journey instead of one straight sequence — and it is the reason this style of development is so popular for object-oriented systems.

Iterative development is built on ideas you already associate with agile practice: continuous integration (merging and testing everyone's work together, frequently), incremental delivery (delivering value in small usable pieces), a lightweight process where nothing is fixed, and small, time-boxed iterations (cycles with a fixed calendar end date), often called sprints. The product itself matters more than documentation; heavy, detailed documentation is deliberately absent. You still produce some documentation, but only the part that genuinely matters — the essential middle slice — and you focus on that. The contrast is with the waterfall model, a sequential process in which the whole design must be finished before implementation can begin. Iterative development rejects that "everything first, then build" stance: you build a little, learn a little, and build again.

4.1.2 What Iterative Development Looks Like

        ┌──────────────────────────────────────────────┐
        ▼                                              │
  Requirements ──► Design ──► Implementation ──► Testing│
  (re-checked)   (re-checked)  (small chunks)  (this   │
       ▲                                              │
       └──────────────────────────────────────────────┘
        each cycle feeds the next, and the user
        reacts to a running demo at the end of each pass

The professor then opened the floor to check prior knowledge and motivation:

The answer connects two ideas: re-validating the requirements repeatedly catches errors that a single pass would miss, and short cycles let the user steer the product before mistakes harden.

4.1.3 Why Iteration Suits Object-Oriented Systems

There is a deeper reason this pairing works: object-oriented development is a bottom-up approach, not a top-down one. You focus on the individual objects or the classes you create, and on the basis of those you build the overall system. When you grow a system out of small, self-contained building blocks, it is natural to develop, test, and replace those blocks in short cycles — exactly what iterations give you. This also means the process itself must be adaptive and flexible. Software development cannot be rigid the way civil engineering or mechanical engineering can be — those are hardcore engineering disciplines where physical rigidity is possible and expected. Software requirements grow and shift, so the process must bend without breaking.

A different analogy, to make the same point stick: building a city from LEGO bricks. You assemble one small building, check it against the picture, then add the next; if a brick is wrong, you swap it out cheaply. The class is the brick, the iteration is one building round, and the check against the picture is user feedback. Nobody assembles the entire city blind and checks the result once at the end.

The evidence from industry history agrees. Iterative development has been used with great success since the 1970s and 1980s — NASA's Project Mercury ran on it, and the Space Shuttle's on-board software went through 17 iterations with a remarkable defect record. Today's Scrum sprints (typically 30 days) are the same idea under a new name. The waterfall, by contrast, is the approach associated with the highest failure rates, lower productivity, and higher defect rates — and its early estimates commonly differ from final actuals by as much as 400%.

4.1.4 The "Code a Bit, Test a Bit" Danger

The warning is about discipline, not about pace. The professor does not object to coding early — he objects to coding with no plan, no architecture, and no feedback loop. The difference between iteration and drift is exactly the full activity set: every cycle must touch requirements, design, implementation, and testing, and must end in something runnable.

4.2 The Best Practices Behind the Unified Process

4.2.1 Where the Best Practices Came From

The Unified Process did not appear out of nowhere — it is a curated set of proven practices. Its intellectual parents are visible in everything it does:

• Iterative life cycle for object-oriented systems. Almost every modern model is iterative in some sense. The spiral model — an iterative, risk-driven process in which each loop adds one refinement of the product while explicitly retiring the biggest remaining risk — is iterative, and so is evolutionary development, where the system grows through successive versions. From the spiral model specifically we inherited the risk-driven approach: the idea that risk gets mitigated in a careful, ordered manner. From agile we inherited the biggest outcome of all: change management, the discipline of accepting changes rather than fighting them.
• Adaptive, lightweight processes. Nothing is fixed; requirements keep on enhancing and growing, so the system — and the process around it — must stay flexible.
• A quality product with continuous verification. Quality is very, very important, and verification comes from continuous testing woven into every iteration, not from one final test pass.
• Documentation only as needed. We saw in the earlier material why documentation matters, but you produce only what is really required, so you do not waste time. The competition will not wait while you write paperwork.

One more lineage fact worth knowing: RUP was commercialized by Rational Software (later acquired by IBM), which is why "Unified Process" and "Rational Unified Process" are often used interchangeably in industry.

4.2.2 Time-Boxed Iterations and Mini Projects

Iterations are time boxed — the calendar length is fixed and cannot move. The class was asked to define the term, and the exchange went like this:

The professor confirmed these were "very good answers" — the two key halves being (1) the fixed calendar that cannot be extended and (2) the small feature set that forces early feedback.

Iteration 1     Iteration 2     Iteration 3       ...   Iteration 8-10
[2-4 weeks]     [2-4 weeks]     [2-4 weeks]             [2-4 weeks]
mini project    mini project    mini project            mini project
   demo             demo            demo                    demo
  stable          stable          stable                  stable
  outcome         outcome         outcome                 outcome

4.2.3 Artifacts: Pick What Matters

The term artifact in the Unified Development Process means everything you produce during development: the documents, the diagrams, the code, the database design, any models you create. You will create many diagrams and many documents, but you do not need all of them. You choose a few artifacts, focus on them, enhance them, and do them in a quality manner.

The professor's analogy for choosing artifacts is a pharmacy:

Real-world: Facing an ailment — sneezing, fever — you find ten or twenty medicines for that ailment on the shelf. The doctor does not prescribe all of them. He chooses according to your symptom, your situation, your environment, your daily routine, and gives you a particular set of doses. Choosing artifacts works the same way: you select the few artifacts with the highest potential value for this particular problem, this particular need. It cannot be generic — the same set cannot serve all projects and all process models.

4.2.4 Analysis Paralysis and Endless Design

The professor flags two failure modes that iterative, time-boxed thinking exists to prevent.

The whole philosophy is a balance: do not rush to code (the analysis and design must happen), but do not wait for everything to be perfect either (the process must not be delayed). The system sits between "rush to code" and "wait forever":

rush to code  ←——————  the balance point  ——————→  wait forever
  (lazy)                                          (analysis paralysis /
   underspecified                                    endless design)

The timebox is the referee: it pushes the "wait forever" side toward action, while the full activity set inside every iteration pulls the "rush to code" side back toward proper analysis and design.

4.2.5 UML as a Best Practice

Another best practice of the Unified Process is UML, the Unified Modeling Language — a standard set of diagramming notations for describing software. The course will use UML throughout, and the professor recommends self-learning the diagrams before the next session; lab sheets will be provided, and you can take any free tool and start building diagrams with it.

Learning UML itself is not a big deal — UML is only notations. But it is good for you because it broadens your thinking. The real skill this course is after is object-oriented thinking; UML is an aid to that thinking and a way to put your ideas in visual form. A lot of visual modeling aids let you represent your ideas to clients and to teammates — showing them, on a diagram, "this is what you are doing, this is what I am thinking." Think back to analysis paralysis: how do you show someone what you are doing? Visual aids are how. Through them you interact, you brainstorm, you get new ideas and new inputs. That is why UML has become a de facto standard for analysis and design across the industry: it is mainly a collection of notations, but those notations give you a shared visual language.

4.2.6 People over Process, and Risk-First Iterations

Two more best practices round out the philosophy. First, the people matter more than the process. In agile thinking, people are the most important component of the system, and the users are the most important people of all. Good people plus a good process gives you better quality than either alone.

Second, sequence your iterations by risk and value. The professor put the question to the class directly:

The same logic applies to change. A change identified in an early iteration is cheap to absorb; a change that surfaces late is very difficult and expensive. Research has proved that identifying changes early saves a lot of time. So you engage your customers continuously — getting feedback, getting their evaluations, collecting new requirements or the changes they want — and you verify what you are building against them at every step.

4.3 Software Architecture

4.3.1 What Software Architecture Is

The professor opened this topic with a direct question to the class, which doubles as the definition:

        ┌──────────┐         ┌──────────────┐         ┌──────────────┐
        │  UI       │ ──────► │ Domain Logic  │ ──────► │ Data Storage │
        │ (view)    │         │ (business)    │         │ (persistence)│
        └──────────┘         └──────────────┘         └──────────────┘
              ▲                     │
              └──── [Security] ─────┘
     components = the boxes   connections = the arrows

4.3.2 Architecture First, Then Build

Architecture has to be built in the early iterations, because it plays an important role in your increments and your iterations. You can deliver your product incrementally only if you have a good architecture — increments need a stable skeleton to attach themselves to. The early architecture also becomes the anchor for future growth: a flexible, open architecture lets you add anything you want later, which is how the system evolves from its initial development through future requirements. The design has to stay flexible precisely so it can absorb that growth.

The professor returns to this later in the session with a house analogy: you build the architecture the way you build a house — you show different aspects through different views. For a building there is a top view, a front view, a side view — the same building seen from different angles — and there is the structure itself, plus the electrical connections and all the different things that need to be there. For software, your architecture also shows the hardware and the technical things you need.

4.3.3 Common Architecture Styles

The course assumes you have met some classic software architecture styles before:

The professor explicitly recommends reading about client-server architecture, because all websites follow it. You do not need to memorize diagram conventions for these now — the point is that the system is described as components plus connections, and that description is the architecture.

4.3.4 The Relative-Effort Picture and What It Teaches

The session returns to a figure shown earlier — the classic unified-process picture of relative effort across disciplines and phases — and the class is pressed to extract the lesson from it. Visual intuition for that figure:

Effort per discipline (height of each band) shifts across the phases

Inception    Elaboration    Construction    Transition
  ▁▂▄           ▅▅▂            ▂▅▅            ▂▂▅
 requirements  requirements   design+code     deployment
 + scope       + architecture + test hump     + final test
   hump            hump           hump            hump

The professor's own summary is worth keeping whole:

• The classes of activity are not one-way; they have to be interactive.
• Work on different disciplines — requirements, analysis, coding, business modeling, testing, implementation — runs in parallel, but at the same time we focus on different stages at different moments. The relative effort in each discipline shifts across the phases.
• An iteration is a mini project, and as you move from iteration to iteration the focus shifts: you get more experience and more learning. Iterative learning development is good for the team.
• The main learning of the picture is that the relative effort changes over time. In every iteration you do everything — requirements, design, business modeling, testing, implementation — but the relative effort shifts across the phases as the project matures.
• Nothing about it is rigid: it varies from organization to organization and project to project.

4.4 Component-Based Software Engineering

4.4.1 Components, Interfaces, and Black Boxes

The goal of CBSE is to build software by connecting various software components, where the components can be connected easily through their interfaces. You want to build your system the way a desktop computer is assembled: buy some off-the-shelf components and integrate them — APIs (application programming interfaces, the defined entry points a component exposes) are one example of such integration points.

The professor's running analogy is hardware, because hardware already achieves what software still cannot:

The professor offers a second hardware analogy — a fan, to which you can add different components — and reminds the class that a computer itself is the best example. The fan's blades, motor, and switch connect through a fixed socket; swap any part and the fan still works, because the socket (the interface) stays the same.

4.4.2 Interface vs Implementation: Polymorphism

        You (caller)                     Die (component)
   "give me the showing face"   ────►   ▒▒▒▒▒▒▒▒▒▒
                                        ▒ black box ▒   six faces,
        (interface: getFace())  ◄────   ▒▒▒▒▒▒▒▒▒▒     each has a value
                                        internal works
                                        hidden from you

A component is also a physical, replaceable part of the system — borrow the term from any physical engineering discipline. The professor points to knee-replacement surgery: the knee is a part of the body's architecture that can be physically replaced, and people do fine. A component conforms to the system the same way: if your interfaces are correct, following the same protocol, you can connect a mouse or a keyboard from any company.

4.4.3 Worked Example: The Die

4.4.4 The Desktop-Computer Example: Why Hardware Leads

The desktop-computer assembly example is the best demonstration that standard interfaces work. Because every keyboard manufacturer builds to the same connector standard, any keyboard works with any machine. Software has not reached that state yet — you cannot yet snap an arbitrary third-party component into an arbitrary system just by matching an interface — and narrowing that gap is what CBSE is about.

Components should be usable or replaceable as black boxes, exactly like the die: you read the showing face without needing to know how the die is made.

4.4.5 Component Diagrams and Packages

In UML there is a component diagram: you show the various components and how they are connected, so that you will be able to deploy your system. There is also a package diagram (a way to group related classes and components into packages). Components are shown in terms of design and implementation — the component diagram lives in the implementation view of the system, next to the class diagrams you draw during design.

4.5 Use-Case-Driven Development

4.5.1 What a Use Case Is

The Unified Process is use-case driven: the use cases are the thread that runs through every phase. A use case is a functionality that has real value to the end user. The definition of a valid use case is strict: it must result in some valuable outcome for the end user. If it does not give any outcome, it is of no use.

The professor explains why use cases became so popular: for a lot of requirements, people say "this is what we know" — or "this is what we don't require" — and you need to connect all the requirements to the users. That is where use case analysis wins. Requirements are not only functional things; a requirement earns its place only if it has a result of value. That "value to the user" test is the main source of the popularity of use case analysis.

4.5.2 Functional vs Non-Functional Requirements

Use cases capture the functional requirements — what the system must do. But the professor asks the class what kinds of requirements exist beyond functional ones. The exchange is a classic misconception-and-correction sequence:

The professor closes the thread by noting that the course will talk about non-functional requirements and how they are captured for a particular organization and a particular project. Notice the discipline here: the professor did not reject the students' first answers as wrong — he corrected them toward the better, more precise term, which is exactly how a vocabulary correction works.

4.5.3 The Real-Requirement Test

A use case answers the question: what is the system supposed to do for the user? The real-requirement test is blunt: if a user needs something out of the system, then it is a real requirement; otherwise it is not real. So you ask the users directly: what benefits do you get? Asking that question produces better use cases.

Use cases are also the guard rail that keeps the evolving design honest. They are used to ensure that the evolving design is always relevant to what the user required — whatever coding, design, and analysis the team is doing, the use cases say whether it is really required by the users or not.

4.5.4 Worked Example: The Dice Game Story

4.5.5 The Use Case Model Governs the Whole Process

The use case model (the collection of use cases, and in this course often called the user model) is used throughout the development of your system:

• You use the use case model for testing — checking whether a requirement is done or not, whether the robustness is there, whether the kind of user is satisfied.
• The whole unified process is governed by this model: you create analysis models based on the use cases, you analyze the use cases, you realize them in the real world, you create design solutions for them, you create the design model, and you write source code for these requirements.

Visual intuition — the use case model as the hub of the process:

                        ┌──► analysis models ──► design model ──► source code
   use case model ──────┤
   (the requirements)   └──► test cases ──► user documentation ──► deployment

For any project, requirements are the main thing that governs the whole technical process or the project development process. Use case analysis has become a de facto standard of requirement analysis in the industry — and the professor notes there is "nothing object related about this": use cases work for any development style, but they fit object-oriented practice particularly well because actors, goals, and stories map naturally onto objects and their interactions.

4.5.6 Roles of Use Cases Across the Lifecycle

Concretely, the use cases do several jobs in the overall system:

1. Identify the users. The first job is to identify the different kinds of users — the classes of users, the roles they play — and their requirements. These user classes become the actors in the use case model. For each actor you identify goals and requirements.
2. Validate the system architecture. Every time you validate and verify what you are doing, the use cases let you check what is really required and whether it is complete. Quality questions about a design — is it complete, is it functional, is it efficient — all come out of this.
3. Define the test cases and procedures. Testing should not begin after coding, or after the product has sometimes already gone to the clients — that is the waterfall pattern and it should not happen. You create your test cases as soon as you have your requirements and use cases. Testing is a very important — and a very big — industry.
4. Plan the iterations. With the number of use cases and the kind of requirements, you can plan your iterations: which use cases fit in which iteration, in what order.
5. Drive user documentation and deployment. The same model produces your user documentation and finally guides the deployment of the system.

Real-world: testing is described as "a very big industry" — test design from use cases is standard practice in professional QA teams, and the test cases you write early, from the requirements, are exactly what waterfall projects discover too late.

4.6 The Four Phases of the Unified Process

4.6.1 Inception: Feasibility and Scope

The Unified Process organizes its iterations into four high-level phases: inception, elaboration, construction, and transition. Inception is your idea. In every iteration, the main outcome of the inception work is a decision: whether to go forward into the next iteration or not — a feasibility test, a go/no-go check.

Inception establishes the business rationale; in this early phase you do the estimations of cost and planning. You define your vision and scope — whatever is really required. The professor stresses the scope boundary: because if you have the complete scope of what you want to do — what is there with you — that makes your life easier. You cannot work things out of scope. You need to define the system boundary for your product: the scope over which you will be working.

(The textbook adds texture here: inception is deliberately short — roughly ten percent of the project — and its purpose is a business case, feasibility, and an order-of-magnitude cost range, not a full requirements specification. That comes later.)

4.6.2 Elaboration: Architecture and Risk

Elaboration is where analysis and design happen: detailed requirement analysis and design, and the risk analysis. Different risks are handled here:

The desired outcomes of elaboration are the use case model, the non-functional requirements, and the domain model. The professor flags the two keywords of this phase: risk management and architecture. You need to know what you are, where you are, and be able to measure it:

Exam note: The textbook chapter on the phases is assigned reading — the recommendation is to read chapter two of the textbook, because the details of what exactly happens in each phase are where the material becomes new.

4.6.3 Construction: Building Increments

Construction is mainly building or writing the code — but any artifact that you are constructing also counts. As an outcome you get product-quality software; coding is the most important aspect as an outcome. In the early iterations, the increments may not be ready for the end user, but some outcome must exist at the end of every iteration.

Construction focuses on completing the implementation: as you refine your use cases and design models, you make them complete, and you produce executable releases of increasing functionality. User documentation, whatever is required, is produced here as well. The construction outcomes include the iteration plan, the design model, and the executable releases.

4.6.4 Transition: Deployment and Beta Testing

Transition is when you take the product to the user community — deploying in the industry or in the real-world domain. This is where beta testing happens, and the professor checks the class's testing knowledge:

Transition ends with installable releases and then a post-mortem analysis of the project's performance — after you complete the product in accordance with the product requirements, you review how the project itself went.

4.6.5 Milestones Are Management Decisions

Various milestones are specified; after a few iterations, their aim is to define or guide your overall development. A milestone is a management decision in the project: it determines whether to authorize movement to the next phase or not — whether you have achieved what that milestone required. The professor's image: going for a long distance, you always need some milestones.

4.6.6 Workflows, Iterations, and Time Boxing Rules

As a definition: a software process is the complete set of activities that you do to transform your user requirements into the product — a definition true of any process model. All the activities are the tasks you do to take the requirements and convert them into a software product. The process has a lifecycle, artifacts, workflows, phases, and iterations. You define your workflows through activity diagrams: a set of activities to be done in parallel or in sequence, together with the different outcomes of all those small activities — and you show the workflows. The releases are cyclic.

The phases are not sequential in the waterfall sense. Every phase contains iterations, and in each iteration you do some construction and some elaboration; the focus of work shifts over time. Inception and transition are very short and very small phases; the main work happens in elaboration and construction. In the figures, the size of the square is related to the time spent — and more time is spent in the initial phases on requirements and analysis:

  Inception    ██
  Elaboration  ██████████████
  Construction ████████████████
  Transition   ██

  (width ≈ time spent; each phase still contains iterations)

The time boxing rules are hard rules:

4.6.7 How Iterations Converge

Each iteration is a cyclic thing: planning, requirements, analysis, implementation — and you keep on evaluating, getting feedback from the end users. Each iteration results in some executable release, which may not be deployed in production. Feedback from iteration n is taken into iteration n+1: you refine, adapt, and grow — incrementally and iteratively, in the same spirit as evolutionary development.

The professor describes the trajectory with a picture: in the initial phases there are hiccups; early iterations sit further from the true path of the system. Suppose you want to go in a straight line — it does not happen. A lot of adaptations and a lot of changes occur, but later on things converge to what is really required and what you have done:

       1     2     3     4     5     6
  x         x                x       x
      x        x       x   x       x     x
        wandering early ──────────► converging later

Every time you get a success in the project development — but there will be challenges. Why do changes become rare in late iterations? Because the cost factor becomes very high and changes become difficult to make. Some organizations do not allow late changes at all. And yet — the professor's nuance — late changes can give an organization competitive business advantage: if you are able to handle later changes as well, and you take them (say a new technology comes out, like ChatGPT, and you incorporate it), you get a high-value product and a competitive advantage over your competitors. Change capability is itself a business weapon.

4.7 People, Project, Process, Product

4.7.1 The Four P's

Every software development effort can be described with four P's: people, project, process, and product. Any software development process takes some requirements as input, and its output is your software system — but those four ingredients determine how well that transformation goes. In agile thinking, people are the most important of the four, then the process; project management exists where a lot of people are involved, and the final product is what you are actually building.

Visual intuition — the process as the container:

        ┌────────────────────────────────────┐
        │            PROCESS                 │
        │   (the container that holds it)    │
        │                                    │
        │   people    project    product     │
        │                                    │
        └────────────────────────────────────┘

4.7.2 What Each P Contributes

4.7.3 People Before Process

The professor's ordering is deliberate: people come before the process. A brilliant process cannot save a weak team — but a strong team can carry a mediocre process. That is why the Unified Process places so much emphasis on the human element, and why the agile mindset treats people as the first P.

The practical consequence: good communication skills are not a nice-to-have — they are what let a team of different roles (analysts, designers, coders, testers) hold the product together. The process organizes them; the people make it work.

4.8 Planning Iterations and the Course Project

4.8.1 The Group Project Exercise

The starting steps for the project:

1. Define the project scope and feasibility for your requirements — your idea.
2. Start making your use case model and domain model, 10 to 20 percent complete.
3. Get your success criteria, an initial plan, and a risk assessment.
4. Set your objectives for the overall project. Usually, in one iteration you would be able to focus on that.

Notice how these steps mirror inception from 4.6: scope, feasibility, use cases, risks, objectives — the go/no-go foundation comes first, then the iterations carry the work forward.

4.8.2 Glossary and Project Repository

The inception artifacts you create include: the vision, the risk list, iteration plans, and the glossary.

The repository is where the project's common understanding lives: the glossary, the models, the plans, and the record of change requirements all sit together so the whole team shares one source of truth.

4.8.3 What Good Iteration Planning Looks Like

Iterations need to be planned in a logical manner. The professor enumerates what good iteration planning buys you:

• The most important risks are handled first — risks are mitigated earlier rather than later, so the biggest unknowns never wait until the end.
• You get visible progress — after every time-boxed iteration there is something to show.
• You can manage the changes — each iteration absorbs feedback, so change becomes a planned event, not a crisis.
• You get reusability — with object orientation, reusability is the most important term, and it is what made this approach so popular. You should be able to reuse what you have already done.
• The project team can learn, and overall better quality comes out of it — every iteration teaches the team something that the next iteration exploits.

4.8.4 Core and Supporting Workflows

The professor frames this project work in terms of workflows — the sets of activities that run across all the iterations and phases:

  Core workflows (every iteration):
  modeling → requirements → analysis & design → implementation → test → deployment

  Supporting workflows (continuously):
  environment │ configuration management │ project management

The glossary and the repository from 4.8.2 are part of this framework: the glossary feeds the requirements and modeling workflows, and the repository is the configuration-management backbone. Good iteration planning (4.8.3) is what the project-management workflow produces.

4.9 The Unified Process Best-Practice Summary

4.9.1 The Consolidated List

4.9.2 Unified Plus Agile for This Course

The professor's suggestion for the course is Unified + Agile: the unified process model with its agile features. The course's main focus is business modeling, requirement analysis, and object-oriented analysis and design; the development would be organized as a series of short, time-boxed iterations with these best practices inside them.

The definition to keep for the exam:

4.10 UML: The Unified Modeling Language

4.10.1 What UML Is and Is Not

UML — the Unified Modeling Language — is a collection of diagrams for visualizing your system. It is a diagramming language: a notation. You can capture both the static and the dynamic behavior of your organization or your system. Importantly, UML is not a methodology. The professor insists on this distinction:

The history explains the name: UML was created by the Object Management Group (OMG) in 1997, with many versions since. During the 1990s a lot of work went into it, and after 2010 it became so standard, so acceptable, that it is now the de facto — and formal — standard throughout the industry.

Real-world: UML is a de facto industry standard. Earlier, everyone used their own notations and their own conventions — that fragmentation was the challenge the OMG unification solved. UML is also "unified" because a large number of people contributed their innovations and their thinking into it.

4.10.2 Static and Dynamic Diagrams

UML is organized into diagram families. The structural diagrams (the static side) include the class diagram, which is very popular, and the package diagram. On the dynamic behavior side you have the activity diagram and the use case diagram — the diagrams the course will actually work with. The professor's practical rule: you will not create every diagram in every project; you create whatever is required. At least the class diagram, the use case diagram, and the activity diagram are expected.

The professor quizzes the class on interaction diagrams:

The component diagram (showing components and their connections, for deployment) and the package diagram belong to the implementation side. In analysis you use analysis diagrams; in design, design diagrams; and there are deployment or implementation diagrams — architecture modeling can be done through UML using all of these. Also note the professor's reminiscence: in earlier times, when the instructor was a student, a cloud was used to denote a class — today a rectangle is used.

4.10.3 Class Diagrams and the Modeling Elements

   ┌──────────────────┐
   │  Dice            │   ← class name (top)
   ├──────────────────┤
   │  faces: int      │   ← attributes (middle)
   │  value: int      │
   ├──────────────────┤
   │  roll(): int     │   ← methods (bottom)
   │  getFace(): int  │
   └──────────────────┘

You should read about why you need modeling, what the purpose of modeling is, and what the different model elements are. The professor's point throughout: in analysis and design the main issue is how to show people what you are doing, and UML is the answer — it is a graphical language for specifying, visualizing, constructing, and documenting the various artifacts of software systems.

4.10.4 History: From Fragmentation to Standard

The unification story: earlier everything was fragmented, everyone using their own notations. Unification started around 1995 onward, a lot of standardization happened, and today UML is a de facto standard in the industry. Three names are credited as the principal people: Booch, Rumbaugh, and Jacobson. But the language also absorbed contributions from many others:

4.10.5 Goals: Machine-Readable Models and OCL

The major goals of UML:

4.10.6 Tools and How to Learn UML

The professor's advice is practical: take a tool and start using it; learn the notations by creating the diagrams. Lab sheets will be provided. Free tools such as StarUML — and, as far as the audio allows, Violet or ArgoUML — will do.

Learning UML is not something great — it is just notations — but it will help you broaden your aspect and your thinking process. The skill this course is after is object-oriented thinking; UML aids it and helps you put your ideas in a visual manner for clients and teammates.

Exam Guidance Summary

The professor's exam guidance for this session, collected in one place — everything below is fair game:

Reading Assignments

• Chapter reading: Chapter two of the textbook is assigned for the phases of the Unified Process — read it, because the per-phase details are where the material becomes new.
• Requirement analysis reading: Read about requirement analysis before starting use case analysis; it is the foundation the use case work builds on.
• UML self-study: Go through the UML diagrams before the next session (activity diagrams, use case diagrams, class diagrams, sequence and communication diagrams). Use any free tool — StarUML, Violet, or ArgoUML — and build diagrams until you are confident with the notations.

The Project Exercise

• Project exercise: Form a group of three or four people and run your project on the Unified Process. Start by defining scope and feasibility; build the use case model and domain model 10 to 20 percent complete; write success criteria, an initial plan, a risk assessment, and objectives. Produce the vision, risk list, iteration plans, and glossary in the first iteration.

Process Facts to Memorize

• Time boxing: Expect iterations of two to four weeks (six weeks maximum; more is not recommended). No deadline extensions: if planned activities do not fit, remove requirements or push them to the next iteration.
• Iteration count: A typical project is planned as 8 to 10 iterations.
• Phase keywords: Inception = feasibility and scope; Elaboration = risk management and architecture (plus the use case model, non-functional requirements, and domain model); Construction = coding and executable releases of increasing functionality; Transition = deployment, beta testing, and post-mortem. Expect the milestone meanings for each phase — each is a management decision to move to the next phase.

Definitions and Reasoning to Be Ready For

• Concepts to be able to define: artifact, time boxing, software architecture, component, interface (vs implementation), use case (valid use case = valuable outcome for the end user), non-functional requirements, glossary, milestones, the four P's (people, project, process, product), and the alpha vs beta testing distinction.
• Process questions to be ready for: why iterative development suits object-oriented systems (changing requirements, user feedback, bottom-up development); why high-risk items go in early iterations; why architecture must be built early; and what the relative-effort picture teaches (relative effort shifts across disciplines and phases; every iteration covers all activities).

Key Industry Applications

The lecture's ideas mapped onto the real world — the professor's recurring examples of where the Unified Process, CBSE, and UML live in industry practice:

Processes in the Industry

• Rational Unified Process (RUP): The commercial form of the Unified Process, influential since around 2000 — the best-practice packaging of iterative, risk-driven, change-managing development.
• Spiral model: The origin of risk-driven development, which the Unified Process adopts as a core idea.
• Agile: The source of change management and lightweight, adaptive processes.

Architecture and Components at Work

• Client-server architecture: The architecture behind essentially all websites — the professor recommends reading about it as the canonical architecture example.
• Component-based software engineering: APIs and off-the-shelf components are the current real-world step toward CBSE; hardware (desktop computers assembled from Samsung, Dell, and HP parts with standard interfaces like the universal keyboard connector) is the model software is trying to catch up with.
• Amazon: A well-known platform of separate services (for example payment) that third parties integrate through well-defined interfaces — the industry-scale picture of CBSE.

UML in the Industry

• UML: De facto and formal industry standard for analysis and design, standardized by the Object Management Group (1997) — used for specifying, visualizing, constructing, and documenting software artifacts.
• UML contributors: Booch, Rumbaugh, Jacobson (creators); Meyer (pre/postconditions); Harel (statecharts); Gamma et al. (design patterns); Shlaer-Mellor (object lifecycles).

Testing, Change, and Risk

• Testing industry: Test case design from use cases; alpha testing in-house vs beta testing in the client domain — testing is described as a very big industry.
• ChatGPT and new technology: Incorporating late-breaking technology into a running project can deliver competitive business advantage — the payoff of good change management.
• Regulatory risk: Data-protection rules and similar government IT regulations can force changes mid-project; political risk is a named risk category in elaboration.
• Medical analogies in engineering: Knee-replacement surgery illustrates physical, replaceable components — the same "physical, replaceable part" idea CBSE wants for software.