Building the Agile Database: How to Build a Successful Application Using Agile Without Sacrificing Data Management
API Design Webinar - Video and Slides « The Amiable API - 0 views
1More
Building the Agile Database: How to Build a Successful Application Using Agile Without ... - 0 views
1More
UML Class Diagrams Examples - Abstract Factory Design Pattern, Library Management, Onli... - 0 views
-
-
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)
-
60More
UML 2 Class Diagram Guidelines - 0 views
-
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
-
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
-
I+ is NOT an acceptable naming convention! this is a very dumb, thoughtless, pointless convention originated by microsoft
-
see http://www.artima.com/objectsandjava/webuscript/PolymorphismInterfaces1.html, 'Interface Naming Conventions'
-
-
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
-
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
-
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
-
-
Make Associations Bi-Directional Only When Collaboration Occurs In Both Directions
-
Question Multiplicities Involving Minimums And Maximums
-
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
-
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
6More
Polymorphism and Interfaces: Chapter 7 of Objects and Java - 0 views
-
Interface Naming Conventions
-
leave off redundant modifiers in member declarations of interfaces
-
either a noun or noun phrase
- ...3 more annotations...
-
if you are using the interface to represent an abstract base class
-
adjective
-
if you are using the interface to represent a behavior
9More
Java Interfaces/Implementation naming convention - Stack Overflow - 0 views
-
Putting I in front is just crappy hungarian style notation tautology that adds nothing but more stuff to type to your code.
-
An Interface in Java is a Type
-
And the Impl suffix is just more noise as well
- ...5 more annotations...
-
Everything that implements Truck is a Type of Truck.
-
The name of the interface should describe the abstract concept the interface represents. Any implementation class should have some sort of specific traits that can be used to give it a more specific name.
-
no justification to have an interface at all.
-
If there is only one implementation class
-
Java Interfaces/Implementation naming convention
-
"Putting I in front is just crappy hungarian style notation tautology that adds nothing but more stuff to type to your code"
23More
Interface naming in Java - Stack Overflow - 0 views
-
interfaces define
-
capabilities
-
this is one sensible interface naming option, if the interface encapsulates a cohesive set of behaviors and yes, compared to blindly following the meaningless I+ convention, it requires some thought, but thinking of an appropriate name also forces you to (re)consider the interface's primary responsibility and how it fits into the overall design imho, a class diagram for a domain model should be almost fluently readable english
-
-
not types
- ...16 more annotations...
-
Comparable
-
Runnable
-
Serializable
-
Sometimes an Adjective doesn't make sense, but I'd still generally be using interfaces to model behavior, actions, capabilities, properties, etc,... not types.
-
Also, If you were really only going to make one User and call it User then what's the point of also having an IUser interface?
-
another anti-pattern... blindly create an interface for every class, even if there's only one implementation!! arrgghhhh! consider introducing an interface when there are 2-3 well-distinguished, concrete implementations required
-
-
if you are going to have a few different types of users that need to implement a common interface, what does appending an "I" to the interface save you in choosing names of the implementations?
-
prefer not to use a prefix on interfaces:
-
hurts readability.
-
interfaces names should be as short and pleasant as possible
-
Implementing classes should be uglier to discourage their use.
-
but they don't *have* to be ugly, like BlahImpl for specialized implementations, use descriptive adjective-noun combos
-
-
Code using an instance of some type should never, ever care if that type is an interface or a class
-
exposing such a detail in the name of the type is pointless and harmful to understanding
-
several reasons Java does not generally use the IUser convention.
-
should not have to know whether the client is using an interface or an implementation class
-
Java naming convention prefers longer names with actual meanings to Hungarian-style prefixes
-
Interface naming in Java [closed]
Agile Modeling (AM) Home Page: Effective Practices for Modeling and Documentation - 0 views
43More
TH03-EP01-US001 - Media Management, Media Upload, Media Item Fields (Groomed BE21, FE8)... - 0 views
-
Media Management,
-
upload a new media item
-
syndication and encoding - not part of this user story
- ...26 more annotations...
-
definition
-
-
Owner
-
Rights of owner
-
dependent on implementation of licensing/rights management system which is tbd, so these will be best guess stubs for now
-
-
Rights expiry date
-
dependent on implementation of licensing/rights management system which is tbd, so these will be best guess stubs for now
-
-
Syndication
-
dumbed down, feature parity implementation is just a list of idss allowed distribution (i believe) use existing legacy infrastructure? ultimate syndication system will depend on: - licensing - explicit list of syndication channels (much like legacy) - rule-based routing
-
-
Caption
-
Category
-
-
Seasonality display rules
-
this is one (simple) example of rule-based syndication: rule type: temporal (which could include: time range, recurrence, end time, etc) rule: syndicate while startDate>=now() and endDate<=now()
-
-
Short description
-
Long description
-
Search keywords
-
Associated with
-
-
in the media library
-
can be viewed by users
-
not only new ecm users, but legacy viewers as well ie. content uploaded via ecm must be available for display in legacy viewers, at least until legacy system is replaced and shutdown for good
-
-
Uploaded by
-
Date uploaded
-
Date modified
-
Last modified by
-
Status
-
TO DO: for new domain model, should define explicit content life cycle with state diagram
-
-
File type
-
Media type
-
Dimensions
-
Aspect ratio
-
aspect ratio doesn't need to be stored in db as metadata, since it can be calculated cheaply based on the dimensions
-
-
File size
-
-
File name
-
is this the original name of the file that was uploaded? if not, and it supposed to be the medlib file name, imho, should not be exposed. the medlib file name should be immaterial to the ecm user and generally, vfml should treat them as opaque to allow future changes without customer dependencies the only time an ecm user should care about a 'file name' is when they're uploading or downloading. but... once the file is uploaded, who cares what the original file name was? it will be recorded, but should be inconsequential to anything since it would never, ever be referred to again on download, (save as...) the original file name *could* be used, but any file name is just as good, since the downloader would also be given the option to rename the file
-
-
Media units consumed
-
calculated/cached value pull from legacy system in future sprints, could start to build phased shell of the marketing xxx system 1. getMediaUnits()
-
TODO: confirm with david and/or henry.wu where/how to obtain 'media units consumed' for a media item
-
Home - JDEclipse-Realign - Mchr3k - 0 views
1More
shared by kuni katsuya on 14 Dec 12
- No Cached
3 simple steps to Ubiquitous Language - Invisible to the eye - 0 views
www.giorgiosironi.com/...ps-to-ubiquitous-language.html
DDD DomainDrivenDesign DomainModel UbiquitousLanguage
shared by kuni katsuya on 14 Dec 12
- No Cached
-
3 simple steps to Ubiquitous Language
34More
Supported Place Types - Google Places API (Experimental) - Google Developers - 0 views
-
Place Types
-
Google Places API
-
supported types for Place searches and Place adds
- ...30 more annotations...
-
Additional types listed in table #2 can be used when searching for a Place,
-
but not when adding a Place
-
so, not treated as a 'full-blown' place type(?) in cube domain model, would this be similar to relationship between hotel ('primary' subject type) and neighborhood ('secondary' subject type, since content can be attached to it, but it would never 'drive' of this relationship)
-
-
airport
-
amusement_park
-
art_gallery
-
shopping_mall
-
restaurant
-
museum
-
night_club
-
place_of_worship
-
train_station
-
lodging
-
hospital
-
These types cannot be used when adding a new Place
-
floor
-
geocode
-
intersection
-
locality
-
neighborhood
-
point_of_interest
-
postal_code
-
postal_code_prefix
-
route
-
street_address
-
street_number
-
sublocality
-
subpremise
-
country
-
administrative_area_level_1 administrative_area_level_2 administrative_area_level_3
-
premise
jiramap.jpg (1007×778) - 0 views
JIRA_Ent_Diagram.jpg (764×353) - 0 views
2More
shared by kuni katsuya on 13 Dec 12
- No Cached
[#GDS-933] GAS3 does not handle Java generics with abstract class implementations - Gra... - 0 views
www.graniteds.org/...GDS-933
java javaee javaee6 graniteds GraniteDS3 JavaGenerics Gas3 CodeGeneration
shared by kuni katsuya on 13 Dec 12
- No Cached
-
GAS3 does not handle Java generics with abstract class implementations
-
Fix Version/s: 3.0.0.M1
4More
Release Notes - GraniteDS - Version 3.0.0.M1 - HTML format - Granite Data Services - 0 views
-
Release Notes - GraniteDS - Version 3.0.0.M1
-
GAS3 does not handle Java generics with abstract class implementations
-
Generated as3 has compilation warnings: missing constructor
- ...1 more annotation...
-
Rename flex-filter to server-filter and @FlexFilter to @ServerFilter
15More
schuchert - JPA Tutorial 4 - Inheritance and Polymorphic Queries - 0 views
-
JPA Tutorial 4 - Inheritance and Polymorphic Queries
-
Books and Dvd's, both of which inherit from Resource
-
When we search for a Resource we might get back Books, Dvd's, or both
- ...12 more annotations...
-
queries polymorphic
-
Introduce the Resource class
-
new type, Dvd
-
What happens when you perform a query on a type that has subclasses?
-
It turns out support for inheritance in queries (as well as JPA) is built in
-
do not actually need to do anything other than have one entity inherit from another entity to get everything to work
-
book entity inherit from the Resource entity
-
Introduce a new entity type called Resource
-
Change the BookDao to be a ResourceDao
-
Update the methods returning Book and have them instead return Resource
-
Update all references to Book and replace them with Resource
-
Change the bookId to resourceId
11More
Inheritance and custom types (Hibernate) - 1 views
-
Choosing a strategy
-
You can apply all mapping strategies to abstract classes
-
and interfaces
- ...8 more annotations...
-
Interfaces may have no state but may contain accessor method declarations, so they can be treated like abstract classes
-
Inheritance and custom types (Hibernate)
-
Mapping class inheritance
-
four different approaches to representing an inheritance hierarchy:
-
Table per concrete class with implicit polymorphism
-
Table per concrete class
-
Table per class hierarchy—
-
Table per subclass
8More
Hibernate - 0 views
-
what-when-how In Depth Tutorials and Information
-
Understanding object/relational persistence (Hibernate)
-
Mapping persistent classes (Hibernate)
- ...5 more annotations...
-
Mapping collections and entity associations (Hibernate)
-
Advanced entity association mappings (Hibernate)
-
Inheritance and custom types (Hibernate)
-
Domain models and metadata (Hibernate)
-
Transactions and concurrency (Hibernate)
View AllMost Active Members
View AllTop 10 Tags
- 160java
- 159javaee6
- 113security
- 100graniteds
- 86CDI
- 85JPA
- 68documentation
- 67Flex
- 62agile
- 61ApacheShiro
- 52jbossas7
- 50database
- 47configuration
- 45BestPractices
- 44jboss
- 44tutorial
- 43authorization
- 38jira
- 38maven
- 37testing