Question 1

UML notation for derived elements: Is a derived attribute or association typically shown with a leading slash “/”, or alternatively by using a stereotype «derived» before the element name?

Accepted Answer

Introduction / Context: The question probes your knowledge of how UML visually marks derived elements—those whose values are computed from other information rather than stored independently. Consistent notation helps reviewers quickly understand which values are calculated and which are base data. Given Data / Assumptions: We are identifying standard UML ways to show derivation. The statement suggests two alternatives: a slash “/” or a stereotype notation «…». We assume common UML 2.x conventions used in practice and tools. Concept / Approach: UML specifies that a derived feature is indicated by a leading forward slash “/” placed before the element’s name. An additional, accepted form is to use a property string such as {derived}. By contrast, a stereotype uses guillemets « » and extends metamodel semantics; «derived» is not the standard way to show a computed property and can be misleading. Therefore, while “/priceWithTax” is correct, claiming that a stereotype before the name is the typical alternative is inaccurate. Step-by-Step Solution: Recognize that “/” marks derivation: for example, /total.Recall the property-string alternative: {derived}.Note that a stereotype «derived» is not the conventional indicator of derivation for attributes/associations.Conclude that the statement is incorrect because it misidentifies the second notation. Verification / Alternative check: Inspect UML references and modeling tools: most show derived features using the “/” prefix and optionally {derived}. Few use a stereotype to convey the same idea for attributes. Why Other Options Are Wrong: “Correct” is wrong because the stereotype claim is not standard. “Only the stereotype” or “derived elements are not marked” contradict mainstream UML practice. “Only the slash; stereotypes are forbidden” overstates—the {derived} property-string is also acceptable. Common Pitfalls: Confusing stereotypes (which extend metaclasses) with property strings; forgetting the leading slash for computed features in diagrams. Final Answer: Incorrect

Question 2

Definition check: In UML and general OO terminology, is a class a concept or abstraction (that is, a “thing” of relevance) that makes sense within the application’s domain context?

Accepted Answer

Introduction / Context: A crisp understanding of what a “class” represents is essential in object-oriented analysis and design. Classes name the significant concepts in a domain and define common structure and behavior for their instances (objects). Selecting the right classes is a key analysis exercise and drives sound design and implementation. Given Data / Assumptions: The statement claims a class is a concept, abstraction, or thing relevant to the application. We assume a UML and OO context where classes define attributes, operations, and relationships. We consider both domain and technical classes (for example, controllers, services). Concept / Approach: In analysis, classes capture domain concepts such as Customer, Order, or Payment. In design, classes also model technical constructs. A class defines the common attributes and operations for all instances and participates in associations, generalizations, and compositions. Therefore, describing a class as a concept or abstraction that makes sense within the application context is accurate and aligns with standard OO literature and UML definitions. Step-by-Step Solution: Identify domain concepts of interest (nouns in requirements).Define classes to encapsulate their attributes (state) and operations (behavior).Relate classes via associations, generalizations, and compositions.Validate that each class represents a meaningful concept for stakeholders. Verification / Alternative check: Check whether instances can be meaningfully created and whether the class supports required behaviors and rules. If yes, the chosen class is a relevant abstraction in the application context. Why Other Options Are Wrong: Limiting the definition to “abstract classes” or “data-only classes” is too narrow. Language dependence is minimal—the conceptual role of classes transcends syntax. Common Pitfalls: Choosing classes that mirror screens or tables without capturing true domain responsibilities; creating anemic models with state but no behavior. Final Answer: Correct

Question 3

Operation types: Is an operation that alters the state of an existing object called a “constructor operation,” or is that term reserved for creating and initializing new instances?

Accepted Answer

Introduction / Context: This question distinguishes between two common operation categories in OO design: constructors and mutators. Mislabeling these can blur the life cycle of objects and lead to misunderstandings in both design documentation and code reviews. Given Data / Assumptions: The statement asserts that an operation which alters the state of an object is a “constructor operation.” We assume mainstream OO languages and UML usage. We distinguish initialization at creation time from subsequent state changes. Concept / Approach: A constructor is an operation invoked when a new object is created; it initializes the new instance’s state. After creation, operations that change an object’s state are typically called mutators, setters, or commands. Therefore, calling any state-altering operation a “constructor” is incorrect: constructors are specifically about creation and initial setup, not ongoing mutations of existing objects. Step-by-Step Solution: Define constructor: operation executed once at instantiation to initialize state.Define mutator: operation that modifies state after the object already exists.Recognize the statement conflates these roles.Conclude that the statement is incorrect. Verification / Alternative check: Inspect languages like Java, C++, C#, or Python: constructors (or init) run at creation; mutator methods (for example, setBalance, applyDiscount) change state later. UML mirrors this practice in sequence and class diagrams. Why Other Options Are Wrong: “Correct” misuses terminology. Prototype-based or manual memory management does not redefine “constructor.” Immutability eliminates mutators but still does not repurpose constructors for later state changes. Common Pitfalls: Treating heavy initialization as general mutation; forgetting to keep constructors side-effect free beyond initialization, which complicates testing and invariants. Final Answer: Incorrect

Question 4

UML class notation: Is a class drawn as a rectangle with three compartments separated by horizontal lines (not vertical), typically for name, attributes, and operations?

Accepted Answer

Introduction / Context: Recognizing standard UML notation is essential for reading and producing consistent design diagrams. The class symbol is among the most frequently used elements. Misremembering its layout can cause confusion when communicating designs across teams. Given Data / Assumptions: The statement claims a class is represented by a rectangle with three compartments separated by vertical lines. Typical UML class notation shows compartments for name, attributes, and operations. We assume mainstream conformance to UML 2.x. Concept / Approach: In UML, a class is drawn as a rectangle partitioned by horizontal lines into up to three compartments: top (name, and possibly stereotypes), middle (attributes), bottom (operations). Vertical partitions are not standard for the class symbol. Some tools allow additional subcompartments (for visibility grouping), but the standard separation is horizontal, not vertical. Therefore, the statement is incorrect. Step-by-Step Solution: Recall the class icon: a rectangle divided horizontally.Top compartment: class name (optionally stereotypes and constraints).Middle: attributes; Bottom: operations.Conclude that “vertical lines” is wrong; horizontal is correct. Verification / Alternative check: Check any UML reference card or modeling tool defaults; class compartments are stacked vertically (separated by horizontal rules). Why Other Options Are Wrong: “Correct” contradicts the spec. Version- or tool-dependence does not switch the basic orientation. Abstract classes use the same symbol, often with italicized name. Common Pitfalls: Confusing class compartments with package or component rendering; overloading diagrams with too many attributes/operations leading to clutter. Final Answer: Incorrect

Question 5

Modeling constraints in UML: When a business rule involves three or more symbols, is it acceptable to present the constraint as a note and attach that note to each applicable symbol with a dashed line?

Accepted Answer

Introduction / Context: Constraints capture additional rules that cannot be expressed simply by standard connectors or multiplicities. UML provides a general note mechanism and an explicit constraint syntax to annotate model elements and relationships, improving precision while keeping diagrams readable. Given Data / Assumptions: A business rule relates three or more model elements. We want a clear, concise way to show the rule without overcomplicating connectors. We use standard UML notation (notes, constraints in braces). Concept / Approach: UML allows attaching a note (a dog-eared rectangle) to one or more elements via a dashed line. A constraint can be written inside the note, often enclosed in braces { } or expressed in a formal language such as OCL. When a rule involves several symbols, linking a single note to each relevant element communicates the dependency clearly and avoids cluttering the diagram with ad-hoc text near each element. Step-by-Step Solution: Write the rule concisely inside a note (for example, {An Order must reference at least one LineItem and one Payment}).Attach the note to all affected elements with dashed lines.Optionally, reference the constraint in documentation or use OCL for formal semantics.Confirm the diagram remains readable and unambiguous. Verification / Alternative check: Compare with embedding text near each symbol or inventing new icons; the note approach is standardized and widely supported by modeling tools, ensuring consistent interpretation. Why Other Options Are Wrong: “Incorrect” ignores standard note usage. Limiting to sequence diagrams or preconditions is inaccurate; notes apply across UML diagram types. A stereotype is unnecessary to express a rule in a note. Common Pitfalls: Overloading notes with long prose; failing to attach the note to all involved elements, which can obscure scope of the rule. Final Answer: Correct

Question 6

Aggregation vs composition: In UML notation, does a filled (solid) diamond at the aggregate end denote composition, a stronger form of aggregation with whole–part lifetime dependency?

Accepted Answer

Introduction / Context: Understanding the visual difference between aggregation and composition in UML helps teams communicate whole–part relationships precisely. Misinterpreting the diamond glyph can reverse the intended semantics, leading to incorrect assumptions about object ownership and lifetime. Given Data / Assumptions: We focus on UML association adornments at the aggregate end. We distinguish shared aggregation from composition. We consider typical object lifetime semantics. Concept / Approach: In UML, an empty (hollow) diamond represents shared aggregation, a weak whole–part relationship (the part may exist independently). A filled (solid) diamond represents composition, a strong whole–part relationship that usually implies the part’s lifetime is bound to the whole. For example, a House composed of Rooms uses a filled diamond at the House end. Thus, the statement correctly identifies the solid diamond as composition. Step-by-Step Solution: Identify the association with a diamond at one end.Check whether the diamond is filled (composition) or hollow (shared aggregation).Interpret the lifetime and ownership semantics accordingly.Conclude the statement is correct: filled equals composition. Verification / Alternative check: Review canonical UML examples: Document–Page (composition); Team–Player (shared aggregation) where players can exist outside a specific team. Modeling tools and reference cards consistently apply this convention. Why Other Options Are Wrong: “Incorrect,” “filled denotes shared,” or “empty denotes composition” invert the standard. “Diamonds are deprecated” is false; while usage is sometimes debated, the symbols remain part of UML. Common Pitfalls: Overusing aggregation where a plain association suffices; assuming composition enforces physical containment rather than conceptual ownership and lifetime binding. Final Answer: Correct

Question 7

UML object diagram basics: Is an object (instance) commonly shown as a rectangle with two compartments—the top for the underlined object name:Class and the lower for attribute slots/values?

Accepted Answer

Introduction / Context: Object diagrams (sometimes called instance diagrams) provide a snapshot of specific objects and their links at a moment in time. Reading their notation correctly helps teams reason about concrete examples of the design and verify multiplicities and constraints with real-looking instances. Given Data / Assumptions: We are describing the standard appearance of an object in a UML object diagram. The statement claims an object uses a rectangle with two compartments: name and attributes. We accept that exact compartments may vary, but we focus on common practice. Concept / Approach: In UML, an object is typically drawn as a rectangle. The top compartment contains the underlined object name, optionally in the form instanceName:ClassName, which makes clear both the specific instance and its type. A second compartment often lists attribute slots with their current values (for example, status = "Shipped"). Additional compartments are not required; operations are usually not shown for instances. Therefore, representing an object with two compartments is a common and correct depiction, though the attribute compartment may be omitted if values are not relevant to the example. Step-by-Step Solution: Draw a rectangle; underline the instance name and show the type as name:Class if desired.Add a second compartment listing attribute slots and values.Connect objects with links to represent associations.Conclude that the statement is correct for standard practice. Verification / Alternative check: Survey UML primers and tool defaults; they show object rectangles with underlined names and (optionally) a second compartment for slots, confirming this conventional representation. Why Other Options Are Wrong: Circles are not the UML default for objects. Exactly three compartments are not required; a single or two-compartment object is common. Objects may show attribute values to illustrate state at a given time. Common Pitfalls: Forgetting to underline the object name; omitting type information when it matters; stuffing methods into an object diagram (they belong to classes, not instances). Final Answer: Correct

Question 8

Object-oriented design concept check: are the common reasons for overriding a superclass method to (1) extend behavior, (2) restrict or specialize behavior for a subclass context, and (3) optimize performance while preserving the contract?

Accepted Answer

Introduction / Context: Method overriding is a core feature of object-oriented programming (OOP). A subclass supplies its own implementation of a method already defined by its superclass. This question asks whether the typical motivations include extension (adding or tailoring behavior), restriction or specialization (narrowing behavior for a specific subtype context), and optimization (improving performance without breaking the public contract). Given Data / Assumptions: We are considering mainstream OOP languages (such as Java, C#, and others) with runtime polymorphism. Overriding should respect the method’s externally observable contract (postconditions, invariants). “Restriction” here refers to specialization appropriate to the subtype, not the illegal strengthening of preconditions for external callers. Concept / Approach: Overriding supports polymorphism: clients call a method on a base type and the subclass version executes. Common reasons include: extending behavior (adding logging, events, or subtype-specific logic), specializing behavior (adapting to subtype invariants such as different validation rules or resource lifecycles), and optimization (for example, caching results or using faster data structures) so long as externally visible effects remain contract-compatible. Step-by-Step Solution: Identify superclass method and its contract (inputs, outputs, side effects).Create a subclass and override the method.Extend or specialize behavior while maintaining compatibility with callers expecting the base contract.Optionally optimize the implementation (e.g., memoization) without altering correct results. Verification / Alternative check: Use unit tests written against the base type. Substitute the subclass and verify all tests still pass, confirming that the override extends/specializes/optimizes without breaking behavior. Why Other Options Are Wrong: Incorrect: Overriding for extension, specialization, and optimization is standard practice. Only applies to abstract methods: Concrete methods can be overridden too (subject to language rules, e.g., not final/sealed). Only performance optimization is valid: Overriding for domain-specific behavior is equally valid. Overriding is discouraged: It is foundational to polymorphism when used judiciously. Common Pitfalls: Violating Liskov Substitution Principle (e.g., strengthening preconditions); altering expected side effects; forgetting to call super when required; breaking invariants. Final Answer: Correct

Question 9

UML associations vs aggregations: is aggregation a stronger form of association shown with a solid (filled) diamond at the aggregate end?

Accepted Answer

Introduction / Context: In Unified Modeling Language (UML), association, aggregation, and composition model “has-a” relationships. Visual notation matters: the diamond adornment differentiates these relationships. The statement claims aggregation uses a solid (filled) diamond and is a stronger association. Given Data / Assumptions: UML distinguishes aggregation (shared-ownership) from composition (strong ownership, whole–part lifecycle). Diagram adornments: hollow (white) diamond for aggregation; solid (filled) diamond for composition. Association lines without diamonds express simple navigable or non-navigable links. Concept / Approach: Aggregation is a specialized association indicating a whole–part with weak ownership. Composition is the stronger form: the part’s lifecycle is bound to the whole (if the whole is destroyed, the parts go with it). Therefore, the solid diamond denotes composition, not aggregation. Aggregation uses a hollow diamond. Step-by-Step Solution: Identify relationship type: association (plain), aggregation (shared), composition (strong).Match to UML notation: aggregation → hollow diamond; composition → solid diamond.Compare strength: composition is stronger than aggregation.Thus the statement claiming “aggregation” is shown with a solid diamond is incorrect. Verification / Alternative check: Consult any standard UML reference: symbol tables consistently use hollow for aggregation, solid for composition. Why Other Options Are Wrong: Correct: Would invert the standard UML meaning. Only true for composition: Indeed, the solid diamond belongs to composition, confirming the statement is incorrect for aggregation. Depends on tool colors: Decoration is semantic, not color theme–dependent. No diamond: Without a diamond, it is a plain association, not aggregation. Common Pitfalls: Confusing aggregation and composition; assuming tool-specific visuals change UML semantics; forgetting lifecycle coupling in composition. Final Answer: Incorrect

Question 10

UML association ends: does every association connect two or more roles (association ends) on participating classifiers?

Accepted Answer

Introduction / Context: UML associations relate classifiers (such as classes) and are drawn as lines between them. Each end of an association is called a role (or association end) and can have multiplicity, navigability, and role names. The question asks whether each association has two or more roles. Given Data / Assumptions: Binary associations connect two classifiers and therefore have two roles. N-ary associations connect more than two classifiers, yielding more than two roles. Self-associations still have two roles (both endpoints on the same classifier). Concept / Approach: By definition, an association has at least two ends; otherwise there is no relationship. In UML, each end is an AssociationEnd with its own multiplicity and properties. Thus every association has two or more roles. There is no meaningful one-ended association in standard UML. Step-by-Step Solution: Consider a binary association between Class A and Class B: roles are A-end and B-end.Consider an n-ary association among A, B, C: roles are at each connected classifier.Even a self-link on A still has two association ends (A↔A), therefore two roles.Hence, “two or more roles” is correct. Verification / Alternative check: Inspect UML metamodel: Association::memberEnd is a collection with size ≥ 2. Why Other Options Are Wrong: Incorrect: Contradicts UML definitions. “Only true for binary associations”: N-ary associations have more than two roles, not fewer. “Only true in EER”: UML’s association concept is independent of EER notation. “Exactly one role”: Not possible in standard UML. Common Pitfalls: Confusing roles with attributes; overlooking that role names are optional even though roles (ends) always exist. Final Answer: Correct

Object-Oriented Data Modeling Questions