Skip to main content

Home/ SoftwareEngineering/ Group items matching "visibility" in title, tags, annotations or url

Group items matching
in title, tags, annotations or url

Sort By: Relevance | Date Filter: All | Bookmarks | Topics Simple Middle
kuni katsuya

UML Class Diagrams - structure diagrams which show architecture of the designed system using class, interface, association, composition, aggregation, dependency, etc. - 0 views

www.uml-diagrams.org/class-diagrams.html

UML ClassDiagram

shared by kuni katsuya on 03 Sep 12 - No Cached
  • «Boundary»
  • Boundary is a stereotyped class or object that represents some system boundary
  • «Control»
  • ...31 more annotations...
  • Control is a stereotyped class or object that is used to model flow of control or some coordination in behavior
  • usually describe some "business logic"
  • «Entity»
  • Entity is a stereotyped class or object that represents some information or data, usually but not necessarily persistent.
  • Features of a class are
  • attributes
  • operations
  • Static features are underlined
  • «Boundary»
  • «Boundary»
  • «Control»
  • «Entity»
  • «Control»
  • Interface
  • An interface is a classifier that declares of a set of coherent public features and obligations
  • specifies a contract.
  • Data Type
  • A data type is a classifier - similar to a class - whose instances are
  • identified only by their value
  • typical use of data types would be to represent value types
  • «dataType»
  • Enumeration
  • An enumeration is a data type whose values are enumerated in the model as user-defined enumeration literals.
  • «enumeration».
  • Multiplicity
  • Multiplicity allows to specify cardinality (allowed number of instances) of described element
  • Visibility
  • UML has the following types of visibility: public package protected private
  • Package visibility is represented by '~' literal.
  • Protected visibility is represented by '#' literal.
  • Private visibility is represented by '-' literal.
kuni katsuya

Feature Visibility [Enterprise Architect User Guide] - 0 views

www.sparxsystems.com/...setfeaturevisibility.html

enterprisearchitect feature visibility verbosity

shared by kuni katsuya on 29 Jun 12 - No Cached
  • enables you to set the visibility of attributes and operations
  • hide or show attributes and operations
  • visibility you set applies only to the current diagram, so a Class can appear in one diagram with all features displayed, and in another with features hidden
kuni katsuya

Why Not Private Visibility For Injected Fields [Screencast] : Adam Bien's Weblog - 0 views

www.adam-bien.com/...why_not_private_visibility_for

package visibility javaee6

shared by kuni katsuya on 03 Jul 12 - No Cached
  • Why Not Private Visibility For Injected Fields
  • Package visibility for injected fields encapsulates way better than public accessors and makes unit testing more convenient at the same time
kuni katsuya

The 4 Most Important Skills for a Software Developer | Javalobby - 0 views

java.dzone.com/...4-most-important-skills

SoftwareEngineer skills

shared by kuni katsuya on 12 Dec 12 - No Cached
  • The 4 Most Important Skills for a Software Developer
  • Skill 1: Solving Problems
  • It is amazing how bad most developers are at solving problems.
  • ...17 more annotations...
  • problem solving is the base skill of software development.
  • Skill 2: Teaching Yourself
  • There is probably no more important skill in life than learning to learn.
  • especially important in software development, because no field I know of changes more rapidly than software development.
  • need the ability to quickly acquire the knowledge you need for the task at hand.
  • learn how to teach yourself
  • Skill 3: Naming
  • Software development is all about describing the metaphysical
  • Every time you are writing code you are naming things
  • can accurately predict a developer’s skill level by looking at how they have named methods, variables and classes in code they have written
  • A developer who lacks the ability to give good names to concepts and data in their code is like a mute translator
  • focus on giving good names to things
  • most visible thing about your code
  • if I read it and can understand it, I am going to assume you know what you are doing.
  • Skill 4: Dealing with People
  • humans are not logical creatures
  • we are emotional ones
kuni katsuya

UML 2 Class Diagram Guidelines - 0 views

www.agilemodeling.com/...classDiagram.htm

uml class diagram best practices

shared by kuni katsuya on 19 Dec 12 - Cached
  • UML 2 Class Diagram Guidelines
  • 1.        General Guidelines
  • 2.        Class Style Guidelines
  • ...49 more annotations...
  • Use Common Terminology for Names
  • Prefer Complete Singular Nouns for Class Names
  • Name Operations with a Strong Verb
  • Name Attributes With a Domain-Based Noun
    • kuni katsuya
      kuni katsuya on 19 Dec 12
       
      don't just use the attribute's type with first character lower cased!!! argghhh!  (eg. instead of Node node, Node parent)
  • Do Not Model Scaffolding Code
  • Include an Ellipsis ( … ) At The End of Incomplete Lists
  • Develop Consistent Method Signatures
  • Avoid Stereotypes Implied By Language Naming Conventions
  • 3.        Interfaces
  • Name Interfaces According To Language Naming Conventions
    • kuni katsuya
      kuni katsuya on 19 Dec 12
       
      I+ is NOT an acceptable naming convention!  this is a very dumb, thoughtless, pointless convention originated by microsoft
    • kuni katsuya
      kuni katsuya on 19 Dec 12
  • Do Not Model the Operations and Attributes of an Interface in Your Classes
  • Consider an Interface to Be a Contract
  • 4.        Relationship Guidelines
  • Model Relationships Horizontally
  • Depict Similar Relationships Involving A Common Class As A Tree
  • Always Indicate the Multiplicity
  • reduce clutter in the diagram
  • Avoid a Multiplicity of “*”
  • Replace Relationships By Indicating Attribute Types
    • kuni katsuya
      kuni katsuya on 19 Dec 12
       
      if dependency relationships were drawn between every class and the types of it's attributes, the class diagram becomes cluttered very quickly this dependency is obvious if the type is indicated for each attribute
  • Do Not Model Every Single Dependency
    • kuni katsuya
      kuni katsuya on 19 Dec 12
       
      generalization of #7 what you show/don't show depends on the main concepts  you're trying to convey in any specific diagram
  • Write Concise Association Names In Active Voice
  • Indicate Directionality To Clarify An Association Name
  • Name Unidirectional Associations In The Same Direction
  • Indicate Role Names When Multiple Associations Between Two Classes Exist
  • Indicate Role Names on Recursive Associations
    • kuni katsuya
      kuni katsuya on 19 Dec 12
       
      eg. parent, child
  • Make Associations Bi-Directional Only When Collaboration Occurs In Both Directions
  • Question Multiplicities Involving Minimums And Maximums
    • kuni katsuya
      kuni katsuya on 19 Dec 12
       
      this just leads to stupid programming practices like hard-coding array sizes, making code more brittle
  • 6.        Inheritance Guidelines
  • “is a”
  • “is like” relationships
  • Apply the Sentence Rule For Inheritance
  • Place Subclasses Below Superclasses
  • A Subclass Should Inherit Everything
    • kuni katsuya
      kuni katsuya on 19 Dec 12
       
      if a subclass sets an attribute to null, implements a method returning null or throwing a NotImplementedException, it really isn't a subclass, or the superclass needs to be decomposed
  • 7.        Aggregation and Composition Guidelines
  • object is made up of other objects
  • aggregation
  • “is part of” relationships
  • whole-part relationship between two objects
  • Composition
  • stronger form of aggregation where the whole and parts have
  • coincident lifetimes, and it is very common for the whole to manage the lifecycle of its parts
  • Apply the Sentence Rule for Aggregation
  • Depict the Whole to the Left of the Part
  • Don’t Worry About Getting the Diamonds Right
  • associations, aggregation, composition, dependencies, inheritance, and realizations
  • line on a UML class diagram
  • defines a cohesive set of behaviors
  • Indicate Visibility Only On Design Models
  • Design Class Diagrams Should Reflect Language Naming Conventions
kuni katsuya

Stephen Colebourne's blog: Javadoc coding standards - 0 views

blog.joda.org/...javadoc-coding-standards.html

java javadoc BestPractices documentation design communication

shared by kuni katsuya on 13 Dec 12 - No Cached
  • Javadoc coding standards
  • explain some of the rationale for some of my choices
  • this is more about the formatting of Javadoc, than the content of Javadoc
  • ...63 more annotations...
  • Each of the guidelines below consists of a short description of the rule and an explanation
  • Write Javadoc to be read as source code
  • Making Javadoc readable as source code
  • Public and protected
  • All public and protected methods should be fully defined with Javadoc
  • Package and private methods do not have to be, but may
  • benefit from it.
    • kuni katsuya
      kuni katsuya on 13 Dec 12
       
      think of it as internal design documentation when you revisit this code 8 months from now: - based on nothing but your well-chosen ;) package/class/method/variable names, will you recall all of your current design intentions and rationale? likely not - when you hand-off this code to another software engineer, how easy will it be to mostly rtfm? will you have to waste time preparing design/implementation notes specifically for the hand-off? if this is the case because the code is unreadable and not self-guiding and there's not already at least high level design notes in a wiki, you're doing it wrong!
  • If a method is overridden in a subclass, Javadoc should only be present if it says something distinct to the original definition of the method
    • kuni katsuya
      kuni katsuya on 13 Dec 12
       
      ie. don't just copy-paste the javadoc from the superclass. that's mindless and pointless monkey work
  • Use the standard style for the Javadoc comment
  • Do not use '**/' at the end of the Javadoc
  • Use simple HTML tags, not valid XHTML
  • XHTML adds many extra tags that make the Javadoc harder to read as source code
  • Use a single <p> tag between paragraphs
  • Place a single <p> tag on the blank line between paragraphs:
    • kuni katsuya
      kuni katsuya on 13 Dec 12
       
      this at least makes the paragraph breaks wysiwygísh and somewhat easier to read
  • Use a single <li> tag for items in a list
  • place a single <li> tag at the start of the line and no closing tag
  • Define a punchy first sentence
  • it has the responsibility of summing up the method or class to readers scanning the class or package
  • the first sentence should be
  • clear and punchy, and generally short
  • use the third person form at the start
  • Avoid the second person form, such as "Get the foo"
  • Use "this" to refer to an instance of the class
  • When referring to an instance of the class being documented, use "this" to reference it.
  • Aim for short single line sentences
  • Wherever possible, make Javadoc sentences fit on a single line
  • favouring between 80 and 120 characters
  • Use @link and @code wisely
  • @link feature creates a visible hyperlink in generated Javadoc to the target
  • @code feature provides a section of fixed-width font, ideal for references to methods and class names
  • Only use @link on the first reference to a specific class or method
  • Use @code for subsequent references.
  • This avoids excessive hyperlinks cluttering up the Javadoc
  • Never use @link in the first sentence
  • Always use @code in the first sentence if necessary
  • Adding a hyperlink in that first sentence makes the higher level documentation more confusing
  • Do not use @code for null, true or false
  • Adding @code for every occurrence is a burden to both the reader and writer of the Javadoc and adds no real value.
  • Use @param, @return and @throws
  • @param entries should be specified in the same order as the parameters
  • @return should be after the @param entries
  • followed by @throws.
  • Use @param for generics
  • correct approach is an @param tag with the parameter name of <T> where T is the type parameter name.
  • Use one blank line before @param
  • This aids readability in source code.
  • Treat @param and @return as a phrase
  • They should start with a lower case letter, typically using the word "the". They should not end with a dot. This aids readability in source code and when generated.
  • treated as phrases rather than complete sentences
  • Treat @throws as an if clause
  • phrase describing the condition
  • Define null-handling for all parameters and return types
    • kuni katsuya
      kuni katsuya on 13 Dec 12
       
      ideally, if the method in question has any specified/required pre and/or post conditions, they should be noted in the javadoc, not *just* null handling also, there are cleaner ways to design around this type of old school null handling hackage
  • methods should define their null-tolerance in the @param or @return
  • standard forms expressing this
  • "not null"
  • "may be null"
  • "null treated as xxx"
    • kuni katsuya
      kuni katsuya on 13 Dec 12
       
      DO NOT DO THIS this is just bad design
  • "null returns xxx"
    • kuni katsuya
      kuni katsuya on 13 Dec 12
       
      this might also stink of poor design ymmv
  • In general the behaviour of the passed in null should be defined
  • Specifications require implementation notes
  • Avoid @author
  • source control system is in a much better position to record authors
  • This wastes everyone's time and decreases the overall value of the documentation. When you have nothing useful to say, say nothing!
    • kuni katsuya
      kuni katsuya on 13 Dec 12
       
      likewise with javadoc on things like default constructors /**  * Creates an instance of SomeClass  */ public SomeClass() {} is equally useless and unnecessarily clutters up the source code
kuni katsuya

Import Binary Module [Enterprise Architect User Guide] - 0 views

www.sparxsystems.com/...importbinary.html

enterprisearchitect jdk import

shared by kuni katsuya on 08 Jul 12 - No Cached
  • Import Binary Module
  • To import a binary module, right-click on the target package in the Project Browser and select the Code Engineering | Import Binary Module context menu option
    • kuni katsuya
      kuni katsuya on 04 Sep 12
       
      note: the file dialog that opens after selecting 'import binary module' opens with filtering for .net binaries, so .jars won't be visible. change filter to .jar and happy happy
    • kuni katsuya
      kuni katsuya on 08 Jul 12
       
      eg. to import jdk classes, import C:\Program Files\Java\jdk1.7.0_05\jre\lib\rt.jar
  • ...2 more annotations...
  • Java Archive (.jar)
  • Do not import private members checkbox excludes private members from libraries from being imported into the model
kuni katsuya

Enterprise JavaBeans 3.1 with Contexts and Dependency Injection: The Perfect Synergy - 0 views

www.oracle.com/...ejb-3-1-175064.html

javaee6 ejb3.1 cdi

shared by kuni katsuya on 12 Jul 12 - No Cached
  • stateless EJB 3.1 bean as boundary (Facade)
  • injected managed beans (controls)
  • @Inject
  • ...22 more annotations...
  • @Inject
  • CDI managed beans. The @EJB annotation is removed and @Inject is used instead
  • Annotating the boundary (Cart) with the @Named annotation makes the Cart immediately visible for expression language (EL) expressions in JSP and JSF
  • @Named annotation takes the simple name of the annotated class, puts the first character in lowercase, and exposes it directly to the JSF pages (or JSP). The Cart bean can be accessed directly, without any backed or managed beans, by the JSF pages: <h:commandButton value="Check out!" action="#{cart.checkout}" />
  • If there is a need for abstraction, the class can be turned into an interface (or abstract class)
  • local implementation (with CDI events
  • @Inject Event<String> event;
  • event.fire("Order proceeded!");
  • remote implementation:
  • javax.enterprise.event.Event belongs to the CDI-implementation
  • class Event can be considered to be a lightweight alternative to the java.beans.PropertyChangeSupport class
  • @Inject Event<String> event;
  • event.fire("Order proceeded!");
  • event can be received by any managed bean and also by EJB beans
  • provide a method with a single @Observes annotated parameter
  • @Observes String event
  • there is no real event, just the payload:
  • The during attribute in the @Observes annotation allows you to select in which transactional phase the event gets delivered. The default setting is IN_PROGRESS, which causes an immediate event delivery regardless of the transaction outcome. The AFTER_SUCCESS configuration causes the delivery to occur only after successful transaction completion
  • Although CDI events work only inside a single process (in the default case, CDI is extensible), they are perfectly suitable for decoupling packages from modules
  • The method checkout() starts a transaction that gets "reused" by the OrderSystem and CustomerNotification session beans
  • ordering.placeOrder(); notifier.sendNotification();
    • kuni katsuya
      kuni katsuya on 18 Jul 12
       
      both run within same transaction
  • EJB beans cannot be directly exposed to JSF or JSP without a little help from CDI
1 - 8 of 8
Showing 20▼ items per page