Module 2 began with modeling.
A model is a purposeful simplification of a system. It includes details that help explain the current purpose and leaves out details that do not.
For a soccer lineup system, useful information might include:
A useful model is not the model with the most information.
It is the model that represents the information needed for the stated purpose.
Abstraction means deciding which real-world details matter to the model.
A player's availability can be important in a lineup system.
The player's favorite movie probably is not.
The same detail can become relevant in a different system.
That means relevance depends on purpose rather than on whether the information is interesting or true.
An object represents one particular instance.
For example:
player1
could identify one particular soccer player object.
A second player would be another object, such as:
player2
Objects can contain selected information in fields.
For example:
player1
name = "Jordan"
jerseyNumber = 7
The object is the specific represented thing.
A field is one named piece of information about that object.
A value is the current information stored in the field.
In a UML object header:
player1 : Player
player1 is the object's identity.
Player is the object's type.
The fields below the header show selected current values.
Two objects can have the same type and still be different instances.
Two objects can even contain matching values and still have different identities.
Objects often gain meaning through their connections.
For example:
player1 : Player -------- team1 : Team
communicates a relationship between those specific object instances.
A relationship is different from a simple field value.
A field stores information about one object.
A relationship connects one object to another object.
A UML object diagram combines:
It represents a particular state of the system.
When reading an object diagram, work from the inside out:
Violet is used to create and revise UML diagrams.
The tool helps you place and connect diagram elements.
It does not decide what belongs in the model.
Modeling decisions still depend on the system purpose, the requirements, and the meaning of the UML.
Editable Violet files are important because diagrams may need to be revised after feedback.
The Feedback System provides information about differences between a submitted artifact and the expected requirements.
A useful workflow is:
Create → Save → Submit → Read the feedback → Revise → Save → Submit again
Feedback should lead to a reasoned correction.
Random changes may eventually alter the message, but they do not build understanding.
Visual Studio is the IDE used for the C# applications in the course.
A solution can contain one or more projects.
A project contains source files and the technical information needed to build that part of the application.
A useful hierarchy is:
Solution → Project → Files
C# source files commonly end in .cs.
WPF applications can also contain XAML files for user-interface structure.
C# source code is text written in the C# language.
During a build, the compiler translates that source into the form used by the .NET runtime.
A useful high-level path is:
C# source → compiler → .NET intermediate form → runtime execution
A successful build means the compiler could translate the current source.
It does not prove that every value or behavior matches the program requirements.
A breakpoint tells Visual Studio to pause when execution reaches a selected statement.
While the program is paused, debugger windows can show current values and objects.
This creates an evidence chain:
Requirement → Source code → Runtime state
If the runtime value does not match what you expected, identify the statement responsible for producing that value and compare it with the requirement.
Consider the UML object:
player1 : Player
-------------------------
name = "Jordan"
jerseyNumber = 7
A simple C# representation might begin with:
Player player1 = new Player();
player1.name = "Jordan";
player1.jerseyNumber = 7;
The UML shows the modeled snapshot.
The C# source contains instructions that create the object and establish its state.
The debugger can show the actual object while the program is running.
These are three different views of the same underlying idea.
new Creates an Object InstanceThe expression:
new Player()
creates a new Player object.
In:
Player player1 = new Player();
the program creates a Player object and gives the code a reference named player1 for working with that object.
Each separate new Player() creates a separate object instance.
Creating two objects does not automatically create a relationship between them.
A programming specification describes what the program must represent or accomplish.
Read a specification by identifying:
Do not turn your first implementation idea into an assumed requirement.
The specification controls what success means.
Several tools and representations appear in this module, and each provides a different kind of evidence.
Specification
What the program is required to accomplish.
UML object diagram
How selected object instances, values, and relationships are represented visually.
C# source code
The instructions used to create and work with running objects.
Build result
Whether the compiler can translate the current source.
Debugger state
What objects and values actually exist while the application is paused.
Feedback System
Information about how the submitted artifact compares with the requirements it evaluates.
Understanding which source answers which question is one of the most important ideas in the module.
Module 2 moves from representation to execution:
Real situation → Model → UML object → C# object creation → Runtime object → Evidence and revision
The details change as you move from one representation to another, but the underlying goal stays the same:
Represent the intended system accurately, use evidence to understand what actually happened, and revise when the result does not match the requirement.