Source code
/* $Id: UMLIncludeBaseListModel.java 17896 2010-01-12 21:36:11Z linus $
*****************************************************************************
* Copyright (c) 2009 Contributors - see below
* All rights reserved. This program and the accompanying materials
* are made available under the terms of the Eclipse Public License v1.0
* which accompanies this distribution, and is available at
* http://www.eclipse.org/legal/epl-v10.html
*
* Contributors:
* bobtarling
*****************************************************************************
*
* Some portions of this file was previously release using the BSD License:
*/
// Copyright (c) 1996-2006 The Regents of the University of California. All
// Rights Reserved. Permission to use, copy, modify, and distribute this
// software and its documentation without fee, and without a written
// agreement is hereby granted, provided that the above copyright notice
// and this paragraph appear in all copies. This software program and
// documentation are copyrighted by The Regents of the University of
// California. The software program and documentation are supplied "AS
// IS", without any accompanying services from The Regents. The Regents
// does not warrant that the operation of the program will be
// uninterrupted or error-free. The end-user understands that the program
// was developed for research purposes and is advised not to rely
// exclusively on the program for any reason. IN NO EVENT SHALL THE
// UNIVERSITY OF CALIFORNIA BE LIABLE TO ANY PARTY FOR DIRECT, INDIRECT,
// SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, INCLUDING LOST PROFITS,
// ARISING OUT OF THE USE OF THIS SOFTWARE AND ITS DOCUMENTATION, EVEN IF
// THE UNIVERSITY OF CALIFORNIA HAS BEEN ADVISED OF THE POSSIBILITY OF
// SUCH DAMAGE. THE UNIVERSITY OF CALIFORNIA SPECIFICALLY DISCLAIMS ANY
// WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
// MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE
// PROVIDED HEREUNDER IS ON AN "AS IS" BASIS, AND THE UNIVERSITY OF
// CALIFORNIA HAS NO OBLIGATIONS TO PROVIDE MAINTENANCE, SUPPORT,
// UPDATES, ENHANCEMENTS, OR MODIFICATIONS.
package org.argouml.core.propertypanels.ui;
import org.argouml.model.Model;
/**
* List model to hold use cases of an includes bases.
*
* @author MarkusK
*/
class UMLIncludeBaseListModel extends UMLIncludeListModel {
/**
* Constructor for UMLIncludeBaseListModel.
*/
public UMLIncludeBaseListModel() {
super("base");
}
/*
* @see org.argouml.uml.ui.UMLModelElementListModel2#buildModelList()
*/
protected void buildModelList() {
super.buildModelList();
addElement(Model.getFacade().getBase(getTarget()));
}
}
Run 1
The code is highly readable with clear structure and intent. It contains a single-purpose class with a simple constructor and one overridden method. Nesting is minimal—only one class level and two short methods with no conditional blocks. Each action (super call, addElement) is on its own line, maintaining good action granularity. The method flow is natural: the overridden method calls the parent implementation then adds a new element, which is intuitive. Copyright headers add length but are standard boilerplate and do not affect the actual code readability. Naming is descriptive, and the Javadoc comments provide context without being excessive. Overall, the logic is concise, well-organized, and easy to follow.
Run 2
The code is generally readable but has significant boilerplate. The structure is logical: package, import, class with a clear inheritance, constructor, and a single overridden method. Nesting is minimal and the method has a flat control flow. Clarity of intent is mostly clear due to concise naming and Javadoc, though the class's exact role relies on familiarity with UML metamodel concepts. Code length is inflated by lengthy license headers, causing a disconnect between the visible source and the actual logic. Action granularity is good — each statement performs one logical action. Reading flow is natural for the small amount of executable code, but the excessive header text obscures the relevant implementation and should be condensed or moved to an external file.
Run 3
The code is highly readable despite containing extensive license headers. It has a clear, logical structure: package declaration, a single import, a focused class definition with a concise constructor, and one overridden method. Nesting is minimal—only one class and one method, with no conditional blocks or loops. Intent is unambiguous: the class extends UMLIncludeListModel to manage use case include bases, with a clear naming convention and a purposeful call to the model facade. Code length is appropriate; the only bloat is the verbose license text, which is not part of the actual logic. Action granularity is excellent, with each statement on its own line and no multiple actions crammed together. The reading flow is natural, moving from constructor to method override, though the license headers interrupt it somewhat. Overall, the implementation is straightforward and clean.
Run 1
Code Structure: Clean organization with a package, import, focused class, constructor, and overridden method. Nesting: Minimal nesting and no conditional complexity. Clarity of intent: Descriptive class and method names reveal the purpose, although the awkward class documentation and reliance on inherited behavior slightly obscure context. Code length: Executable code is concise; the extensive license header increases reading overhead without adding implementation complexity. Action granularity: Each statement performs a distinct action; the chained facade call remains understandable. Reading flow: Conventional Java layout and consistent formatting make the implementation easy to follow, though redundant constructor documentation and the missing @Override annotation are minor readability weaknesses.
Run 2
Code Structure: The class is logically organized, with a constructor followed by a focused overridden method. Nesting: There is no control-flow nesting, making the implementation easy to scan. Clarity of intent: Class and method names communicate the list-model purpose, although the awkward class documentation and reliance on inherited behavior slightly obscure details. Code length: The executable code is concise; the lengthy licensing header adds substantial visual overhead but is separate from the implementation. Action granularity: Each statement performs a distinct action, although the chained facade call requires some API familiarity. Reading flow: Consistent formatting and straightforward sequencing provide a natural flow from initialization to model population.
Run 3
Code Structure: The class is logically organized, with a constructor followed by a focused overridden method. Nesting: There is no control-flow nesting, making execution easy to follow. Clarity of intent: Class and method names communicate the list-model purpose, although the awkward class documentation and reliance on inherited behavior slightly obscure context. Code length: Executable code is concise; the extensive licensing header adds visual bulk but is separate from the implementation. Action granularity: Each statement performs one main action, though the chained facade call combines several lookups into one expression. Reading flow: Consistent formatting and a straightforward initialization-then-population sequence support natural reading.