Skip to main content

Home/ SoftwareEngineering/ Group items tagged ClassDiagram

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
kuni katsuya

UML Class Diagrams Examples - Abstract Factory Design Pattern, Library Management, Onli... - 0 views

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

UML ClassDiagram examples

shared by kuni katsuya on 19 Dec 12 - No Cached
    • kuni katsuya
      kuni katsuya on 19 Dec 12
       
      note lack of dependency lines between a class and the types of it's attributes (eg. no dependency line drawn between Order->OrderStatus or WebUser->UserState. these are obvious and would just clutter the diagram)
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

UML Class Diagrams - structure diagrams which show architecture of the designed system ... - 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.
1 - 5 of 5
Showing 20▼ items per page