Skip to main content

Home/ SoftwareEngineering/ Group items tagged models

Rss Feed Group items tagged

kuni katsuya

Introduction to Enterprise Architect, UML Modeling Tool [EA User Guide] - 0 views

  • Introduction to Enterprise Architect
  • Enterprise Architect User Guide provides tutorials, guidance and reference material to help you use Enterprise Architect in: Modeling With Enterprise Architect Model Management Project Management Model Auditing Model Baselining and Differencing Model User Security Model Version Control Code Engineering Visualization and Analysis of Code Execution RTF and HTML Document Creation (Reports)
  • Introduction to Enterprise Architect
  • ...2 more annotations...
  • Enterprise Architect User Guide provides tutorials, guidance and reference material to help you use Enterprise Architect in: Modeling With Enterprise Architect Model Management Project Management Model Auditing Model Baselining and Differencing Model User Security Model Version Control Code Engineering Visualization and Analysis of Code Execution RTF and HTML Document Creation (Reports)
  • If you are new to modeling and UML as well as Enterprise Architect, or otherwise want a rapid review of the process of modeling with Enterprise Architect, go to the Quickstart Tutorial.
kuni katsuya

UML tools for software development and Modelling - Enterprise Architect Full Lifecycle ... - 0 views

  • EA User Guide (pdf)
  • Reference Booklets
  • Enterprise Architect Online Help
  • ...8 more annotations...
  • Tutorials All Tutorials UML Tutorials UML 2.1 Tutorial UML Tutorial - Part 1 Intro UML Tutorial - Part 2 Intro The Business Process Model The Component Model The Dynamic Model The Logical Model The Physical Model The Use Case Model UML Database Modeling Enterprise Architect Tutorials Creating Strategic Models Diagram Filters BPEL: Step by Step Guide Resource Management Testing Management Traceability RTF Documentation Use Case Metrics Structured Use Case Scenarios
  • Video Demonstrations All Videos Getting Started Requirements Management Modeling & Productivity Tools Code Engineering and the Debug Workbench Version Control Integration (Eclipse, Visual Studio, TFS)
  • UML Tutorial - Structure UML Tutorial - Behavior The Business Process Model Deployment of EA MDA Overview Rich-Text (RTF) Reporting Version Control Integration Requirements Management
  • White Papers & E-Books
  • Roles Business Analyst Database Administrator Deployment & Rollout Developer Project Manager Software Architects Software Engineer Technology Developer Testers
  • Solutions
  • MDG Technologies MDG Technologies EJB Technology.xml Testing Technology.xml
  • UML Profiles & Patterns UML Patterns UML Patterns Create UML Patterns Import UML Patterns Use UML Patterns UML Profiles UML Profiles: Introduction UML Profile for SPEM XML Schema (XSD) Generation Web Modeling Profile Eriksson-Penker Business Extensions Open Distributed Processing (UML4ODP)
kuni katsuya

Entity-attribute-value model - Wikipedia, the free encyclopedia - 0 views

  • Entity–attribute–value model
  • Entity–attribute–value model (EAV) is a data model to describe entities where the number of attributes (properties, parameters) that can be used to describe them is potentially vast, but the number that will actually apply to a given entity is relatively modest
  • also known as object–attribute–value model, vertical database model and open schema
  • ...21 more annotations...
  • In an EAV data model, each attribute-value pair is a fact describing an entity, and a row in an EAV table stores a single fact
  • EAV tables are often described as "long and skinny": "long" refers to the number of rows, "skinny" to the few columns
  • Data is recorded as three columns: The entity: the item being described. The attribute or parameter: a foreign key into a table of attribute definitions. At the very least, the attribute definitions table would contain the following columns: an attribute ID, attribute name, description, data type, and columns assisting input validation
  • The value of the attribute
  • Row modeling, where facts about something (in this case, a sales transaction) are recorded as multiple rows rather than multiple columns
  • differences between row modeling and EAV (which may be considered a generalization of row-modeling) are:
  • A row-modeled table is homogeneous in the facts that it describes
  • The data type of the value column/s in a row-modeled table is pre-determined by the nature of the facts it records. By contrast, in an EAV table, the conceptual data type of a value in a particular row depend on the attribute in that row
  • In the EAV table itself, this is just an attribute ID, a foreign key into an Attribute Definitions table
  • The Attribute
  • The Value
  • Coercing all values into strings
  • larger systems use separate EAV tables for each data type (including binary large objects, "BLOBS"), with the metadata for a given attribute identifying the EAV table in which its data will be stored
  • Where an EAV system is implemented through RDF, the RDF Schema language may conveniently be used to express such metadata
  • access to metadata must be restricted, and an audit trail of accesses and changes put into place to deal with situations where multiple individuals have metadata access
  • quality of the annotation and documentation within the metadata (i.e., the narrative/explanatory text in the descriptive columns of the metadata sub-schema) must be much higher, in order to facilitate understanding by various members of the development team.
  • Attribute metadata
  • Validation metadata include data type, range of permissible values or membership in a set of values, regular expression match, default value, and whether the value is permitted to be null
    • kuni katsuya
       
      jsr-299 bean validation anyone?  :)
  • Presentation metadata: how the attribute is to be displayed to the user
  • Grouping metadata: Attributes are typically presented as part of a higher-order group, e.g., a specialty-specific form. Grouping metadata includes information such as the order in which attributes are presented
  • Advanced validation metadata Dependency metadata:
kuni katsuya

Enterprise Architect - Resources - Model Driven Generation (MDG) Technologies - 0 views

  • Model Driven Generation (MDG) Technologies
  • MDG Technologies allow users to extend Enterprise Architect's modeling capabilities to specific domains and notations. MDG Technologies seamlessly plug into Enterprise Architect to provide additional toolboxes, UML profiles, patterns, templates and other modeling resources.
  • Free MDG Technology downloads for Enterprise Architect:
  • ...12 more annotations...
  • EJB MDG Technology for Enterprise Java Beans allows the user to model EJB entities and EJB sessions, complete with UML profiles for modeling EJB, EJB patterns and Code Management. (requires Enterprise Architect 4.1 or later)
  • ICONIX AGILE DDT ICONIX Agile Developer - Design-Driven Testing (DDT) streamlines the ICONIX modeling process, providing: Convenient modeling of robustness diagrams Automatic generation of sequence diagram structures from robustness diagrams Transformation of robustness control elements to test diagrams Transformation of sequence diagram elements to test diagrams Transformation of requirement diagrams to test diagrams Transformation between test cases and test classes. (JUnit & NUnit) Built-in model validation rules for ICONIX robustness diagrams (requires Enterprise Architect 7.5 or later)
  • Testing MDG Technology for Testing helps users to rapidly model a wide range of testing procedures including component testing, SUT, Test Cases and more. (requires Enterprise Architect 4.1 or later)
  • Instructions for loading an MDG Technology EXE file: Download and run the .exe file to install the MDG technology. Open Enterprise Architect. Select from the Main Menu Add-Ins | XYZ Technology | Load.
  • Built-in MDG Technologies: Most of the MDG Technologies provided by Sparx Systems are built into Enterprise Architect directly. Depending on your edition of Enterprise Architect, some or all of the following MDG Technologies will be available:
  • Gang of Four Patterns
  • Mind Mapping
  • Web Modeling
  • Data Flow (DFD)
  • Entity-Relationship (ERD)
  • Business Rule Model
  • BPMN™
kuni katsuya

Enterprise Architect - Product Demonstrations - 0 views

  • Part 2 Subversion Setting up a Subversion repository for use with Enterprise Architect models.
  • Part 4 Configure & Connect Configuring Enterprise Architect and connecting to your Version Control system.
  • Part 5 Controlled Packages Working with version controlled UML packages in Enterprise Architect.
  • ...19 more annotations...
  • Eclipse A tour of MDG Integration for Eclipse.
  • Baseline Diagram Comparison Conduct a visual diagram comparison between your current diagram and a previous baseline .
  • Personal Information Window See how the Personal Information Window in Enterprise Architect can help you organize your daily tasks and workflow.
  • Working Sets As you perform work on your model, you open various windows, diagrams and views. Working Sets allow you to return to these same views in a later work session.
  • Business Rules A car rental system is used to illustrate how to generate executable business rules using Enterprise Architect.
  • Menu Customization Quickly and easily suppress individual menu items or entire categories of commands to create custom menu layouts.
  • Floating and Dockable Windows Save the position and layout of Floating and Dockable Windows using a Working Set in the Personal Information Window.
  • Build and Debug a Java Application Set up Enterprise Architect to build and debug a Java Application, using a VEA sample project.
  • Sequence Diagrams Learn how to create a simple Sequence diagram. The video also illustrates how to bring your Sequence diagram to life using model simulation.
  • HTML Report Generation This brief introduction illustrates how to automatically generate a HTML Report using Enterprise Architect.
  • Basic Use Case Demonstration A guide to constructing a Use Case model in under 30 seconds, including use cases, notes and issues.
  • Traceability within Enterprise Architect This video examines Traceability and discusses how to use Enterprise Architect to conduct an Impact Analysis.
  • Requirements Reporting A brief overview of requirements reporting in Enterprise Architect. Topics include document generation in web and RTF formats, report customization and virtual documents, including Model and Master documents.
  • Requirements Traceability An examination of requirements traceability in Enterprise Architect. Topics include traceability views, tracing to external artifacts, conducting an impact analysis, viewing the Relationship Matrix and using Enterprise Architect's Auditing capabilities.
  • Requirements Modeling A brief overview of requirements modeling in Enterprise Architect. Topics include requirements capture and definition, custom properties, tabular editing, auto-naming and screen prototypes.
  • Installing EA An introductory walk through and discussion of Enterprise Architect in the Software Development Lifecycle.
  • Enterprise Architect 7.5 Overview An overview of Enterprise Architect features released with version 7.5.
  • Introduction to Enterprise Architect An introductory walk through and discussion of Enterprise Architect in the Software Development Lifecycle.
  • Brief Overview The 10 minute guide to Enterprise Architect, from Requirements Management and Business Process Modeling to MDA and Code Engineering.
kuni katsuya

Access control - Wikipedia, the free encyclopedia - 0 views

  • Computer security
  • authentication, authorization and audit
  • In any access control model, the entities that can perform actions in the system are called subjects, and the entities representing resources to which access may need to be controlled are called objects
  • ...39 more annotations...
  • Principle of least privilege
  • object-capability model, any software entity can potentially act as both a subject and object
  • Access control models used by current systems tend to fall into one of two classes:
  • those based on capabilities
  • those based on access control lists (ACLs)
  • Both capability-based and ACL-based models have mechanisms to allow access rights to be granted to all members of a group of subjects (often the group is itself modeled as a subject)
  • identification and authentication determine who can log on to a system, and the association of users with the software subjects that they are able to control as a result of logging in; authorization determines what a subject can do; accountability identifies what a subject (or all subjects associated with a user) did.
  • Authorization determines what a subject can do on the system
  • Authorization
  • Access control models
  • categorized as either discretionary or non-discretionary
  • three most widely recognized models are
  • Discretionary Access Control (DAC)
  • Mandatory Access Control (MAC)
  • Role Based Access Control (RBAC)
  • Attribute-based access control
  • Discretionary access control
  • Discretionary access control (DAC) is a policy determined by the owner of an object. The owner decides who is allowed to access the object and what privileges they have.
  • Every object in the system has an owner
  • access policy for an object is determined by its owner
  • DAC systems, each object's initial owner is the subject that caused it to be created
  • Mandatory access control
  • Mandatory access control refers to allowing access to a resource
  • if and only if rules exist
  • that allow a given user to access the resource
  • Management is often simplified (over what can be required) if the information can be protected using
  • hierarchical access control
  • or by implementing sensitivity labels.
  • Sensitivity labels
  • A subject's sensitivity label specifies its
  • level of trust
  • level of trust required for access
  • subject must have a sensitivity level equal to or higher than the requested object
  • Role-based access control
  • Role-based access control (RBAC) is an
  • access policy
  • determined by the system
  • not the owner
  • Access control
kuni katsuya

DDD: putting the model to work - 0 views

  • DDD: putting the model to work
  • foundations of domain-driven design:How models are chosen and evaluated;How multiple models coexist;How the patterns help avoid the common pitfalls, such as overly interconnected models;How developers and domain experts together in a DDD team engage in deeper exploration of their problem domain and make that understanding tangible as a practical software design.
kuni katsuya

AnemicDomainModel - 0 views

  • AnemicDomainModel
  • Eric Evans
  • basic symptom of an Anemic Domain Model
  • ...40 more annotations...
  • The catch comes when you look at the
  • behavior
  • there is hardly any behavior on these objects, making them little more than bags of getters and setters
  • I was chatting with
    • kuni katsuya
       
      note, the 'i' here, is mr. MARTIN FOWLER!! and of course, eric evans hails from domain driven design fame
  • fundamental horror
  • it's so contrary to the basic idea of object-oriented design
  • combine
  • data and process together
  • procedural style design
  • completely miss the point of what object-oriented design is all about
  • It's also worth emphasizing that putting behavior into the domain objects
  • should not contradict the solid approach of using layering to separate domain logic from such things as persistence and presentation responsibilities
  • logic that should be in a domain object is domain logic
  • validations
  • calculations
  • business rules
  • One source of confusion in all this is that many OO experts do recommend putting a layer of procedural services on top of a domain model, to form a Service Layer
  • this isn't an argument to make the domain model
  • void of behavior
  • service layer advocates use a service layer in conjunction with a behaviorally rich domain model.
  • does not contain business rules or knowledge, but
  • only coordinates
  • tasks and delegates work to
  • collaborations of domain objects
  • in the next layer down
  • can have state that reflects the
  • progress of a task
  • for the user or the program
  • Domain Layer
  • Application Layer
  • Service Layer
  • Responsible for
  • representing concepts of the business
  • business rules
  • This layer is the heart of business software
    • kuni katsuya
       
      ... and has the *most value* to an organization investing in writing their own software infrastructure software (eg. user interface, orm, application server-related frameworks) or plumbing code should be treated as commodities where possible, unless, the business consciously decides that a custom, home-grown implementation is absolutely required for patenting or other differentiation reasons and/or that no existing off-the-shelf solution can be used but these cases should be rare! do not blindly fall for the not-invented-here syndrome
  • all the key logic lies in the domain layer
  • I don't know why this anti-pattern is so common
  • if they come from a
  • data background
    • kuni katsuya
       
      this is why during every sprint, i reiterate that the data model up approach to designing the system is OH SO WRONG but nobody listens
  • J2EE's Entity Beans
    • kuni katsuya
       
      damn baggage from  eons ago!!!
kuni katsuya

Anemic domain model - Wikipedia, the free encyclopedia - 0 views

  • objects containing only data
    • kuni katsuya
       
      ie. dumb data structures with little or no behavior
  • objects containing only code
    • kuni katsuya
       
      ie. classes that are just containers for methods that implement the behavior part of the domain objects (aka the procedures)
  • Martin Fowler, who considers the practice an anti-pattern
  • ...14 more annotations...
  • Benefit
    • kuni katsuya
       
      none
  • Liabilities
    • kuni katsuya
       
      lots
  • Logic cannot be implemented in a truly object-oriented way
    • kuni katsuya
       
      for example, polymorphic behavior
    • kuni katsuya
       
      dammit, can't change highlight color if there's also a sticky note attached!!! arrgggghhhh!!! diigo plugin bug!!
  • Violation of the encapsulation
  • domain model's objects cannot guarantee their correctness
  • validation and mutation logic is placed somewhere outside
    • kuni katsuya
       
      instead of, say, attaching validation 'behavior' directly on, but still decoupled from domain classes themselves (eg. validation rule annotations on jpa entity beans)
    • kuni katsuya
       
      dammit, can't change highlight color if there's also a sticky note attached!!! arrgggghhhh!!! diigo plugin bug!!
  • Necessitates a service layer when sharing domain logic across differing consumers of an object model.
  • Makes a model less expressive and harder to understand.
  • Facilitates code duplication among transactional scripts and similar use cases, reduces code reuse.
  • Liabilities
  • Liabilities
  • Liabilities
  • Liabilities
  • Liabilities
kuni katsuya

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
    • kuni katsuya
       
      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
       
      I+ is NOT an acceptable naming convention!  this is a very dumb, thoughtless, pointless convention originated by microsoft
    • kuni katsuya
  • 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
       
      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
       
      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
       
      eg. parent, child
  • Make Associations Bi-Directional Only When Collaboration Occurs In Both Directions
  • Question Multiplicities Involving Minimums And Maximums
    • kuni katsuya
       
      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
       
      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

List of E-Books - 0 views

  • Modeling Service Oriented-Architectures: An Illustrated Example using Sparx Systems Enterprise Architect
  • Download the E-book in PDF format Download the E-book, Roadmap, Project Template and Rental Car example as a zip file
  • In our third E-book, author Doug Rosenberg (Founder and President of ICONIX Software Engineering, Inc) presents a practical approach to modeling Service-Oriented Architecture solutions from concept to code.
  • ...2 more annotations...
  • Purchase the book at http://leanpub.com/entarch
  • 50 Enterprise Architect Tricks can help you work with elements, diagrams, tagged values, connectors and many other advanced topics.
kuni katsuya

Seam Framework - What is the purpose of the @Model annotation? - 0 views

  • A stereotype is an annotation that aggregates other annotations
  • @Named @RequestScoped @Stereotype
  • @interface Model
  • ...3 more annotations...
  • @Model stereotype; it lets you give a bean a name, and set its scope to @RequestScoped in one stroke
  • What is the purpose of the @Model annotation?
  • The @Model annotation does to things: it makes the bean request-scoped (instead of dependent, the default) it gives the bean an EL name
  •  
    A stereotype is an annotation that aggregates other annotations
kuni katsuya

Enterprise Architect - UML Design Tools and UML CASE tools for software development - 0 views

  • Code Engineering Database Engineering Debug & Visualize Applications MDG Technologies (Create & Use)* Model Driven Architecture (MDA) Project Discussion Forum Replicate .EAP Projects Reverse Engineer Binaries (Java, .NET) Shared Models WSDL Engineering XML Schema (XSD) Engineering
  • Audit Model Changes Baseline Diff/Merge DBMS Repository** Floating Edition Available Lazy Load Scripting with JScript, VBScript and Javascript Security (Role-based) WAN Optimizer
  • BPEL Generation from BPMN diagrams Business Rules Composer Executable Code Generation from Behavioral Models Math Support built into Script Engines
  • ...5 more annotations...
  • Allocated Work Execution Analyzer Menu Test Points Win 32 User Interface Designs Business Process Simulation ***
  • Gap Analysis Model Mail Project Calendar Task Allocations TOGAF Gap Analysis
  • BPEL 2.0 Generation BPMN Simulation SysML 1.2
  • Eclipse Integration
  • Eclipse Link
  •  
    Code Engineering Database Engineering Debug & Visualize Applications MDG Technologies (Create & Use)*
kuni katsuya

Java Persistence/Inheritance - Wikibooks, open books for an open world - 0 views

  • Inheritance
  • hardest part of persisting inheritance is choosing how to represent the inheritance in the database
  • There are three inheritance strategies defined from the InheritanceType enum,
  • ...101 more annotations...
  • SINGLE_TABLE
  • TABLE_PER_CLASS
  • JOINED
  • Single table inheritance is the default
  • @MappedSuperclass
  • @Inheritance
  • mapped superclass is
  • not a persistent class
  • but allow common mappings to be define for its subclasses
  • Single Table Inheritance
    • kuni katsuya
       
      implemented as a sparse table. ie. all attributes from all entities end up as columns in the 'super' table
  • single table is used to store all of the instances of the entire inheritance hierarchy
  • table will have a column for
  • every attribute
  • every class
  • in the hierarchy
  • discriminator column
  • is used to determine which class the particular row belongs to
  • abstract
  • Project
  • extends Project
  • extends Project
  • @DiscriminatorValue("S")
  • @DiscriminatorValue("L")
  • @DiscriminatorColumn(name="PROJ_TYPE")
  • @Inheritance
  • @Table(name="PROJECT")
  • single table inheritance
  • Joined, Multiple Table Inheritance
  • mirrors the object model in the data model
  • table is defined for each class in the inheritance hierarchy to store only the local attributes of that class
  • Each table in the hierarchy must also store the object's id (primary key), which is
  • only defined in the root class
  • share the same id attribute
  • joined inheritance
  • @Inheritance(strategy=
  • InheritanceType.JOINED
  • @DiscriminatorColumn(name="PROJ_TYPE")
  • @Table(name="PROJECT")
  • abstract
  • Project
  • @DiscriminatorValue("L")
  • @Table(name=
  • "LARGEPROJECT"
  • LargeProject
  • Project
  • @DiscriminatorValue("S")
  • @Table(name=
  • "SMALLPROJECT"
  • SmallProject
  • Project
  • Table Per Class Inheritance
  • Advanced
  • table is defined for
  • each concrete class
  • in the inheritance hierarchy to store
  • all the attributes
  • of that class and
  • all of its superclasses
  • table per class inheritance
  • @Inheritance(strategy=
  • InheritanceType.TABLE_PER_CLASS
  • abstract
  • Project
  • @Table(name="LARGEPROJECT")
  • LargeProject
  • Project
  • @Table(name="SMALLPROJECT")
  • SmallProject
  • Project
  • Mapped Superclasses
  • similar to table per class inheritance, but does not allow querying, persisting, or relationships to the superclass
  • mapped superclass
  • @MappedSuperclass
  • abstract
  • Project
  • @Column(name="NAME")
  • @Table(name="LARGEPROJECT")
  • LargeProject
  • Project
  • @AttributeOverride
  • "PROJECT_NAME"
  • "name"
  • @Table("SMALLPROJECT")
  • SmallProject
  • Project
  • cannot have a relationship to a mapped superclass
  • Joined, Multiple Table Inheritance
  • oined, Multiple Table Inheritance
  • abstract
  • abstract c
  • extends Project
  • Mapped Superclasses
  • Mapped Superclasses
  • apped Superclasses
  • allows inheritance to be used in the object model, when it does not exist in the data model
  • @MappedSuperclass
  • MappedSuperclass
  • abstract
  • abstract
  • extends Project
  • extends Project
kuni katsuya

VineetReynolds / Java EE 6-Galleria / wiki / DataModel - Bitbucket - 1 views

  • Many users can be associated with a group
    • kuni katsuya
       
      user:group = n:m (ie. many-to-many)
  • Groups
  • groupId.
  • ...5 more annotations...
  • A User
  • userId
  • Users can have many Albums
    • kuni katsuya
       
      user:album = 1:n
  • Album containing Photos
    • kuni katsuya
       
      album:photo = 1:n
  • Physical Data Model
    • kuni katsuya
       
      ie. er model in database
  •  
    Logical Data Model
kuni katsuya

graniteds - can newer web containers having Servlet 3 extend BlazeDS max # of simultane... - 0 views

  • GraniteDS & Asynchronous Servlets
  • to handle many thousands concurrent users, you can even
  • create a cluster of GraniteDS servers
  • ...9 more annotations...
  • Asynchronous Servlets Performance
  • With a non NIO or non Continuation based server, this would require around 11,000 threads to handle 10,000 simultaneous users. Jetty handles this number of connections with only 250 threads.
  • Classical synchronous model: 10,000 concurrent users -> 11,000 server threads. 1.1 ratio.
  • Comet asynchronous model: 10,000 concurrent users -> 250 server threads. 0.025 ratio.
  • classical (synchronous) servlet model
  • request -> immediate processing -> response
  • Comet implementations rely on a different model:
  • request -> wait for available data -> response
  • With synchronous servlet processing, each request is handled by one dedicated server thread
kuni katsuya

Agile/Evolutionary Data Modeling: From Domain Modeling to Physical Modeling - 0 views

  • serial approach which risks communication errors
    • kuni katsuya
       
      serial approach, aka 'throw it over the wall' approach
  • parallel approach which risks double work (both of us would have explored the same schema issues, her from an object point of view and me from the data point of view) and incompatible work (we could have easily made different schema design decisions)
1 - 20 of 92 Next › Last »
Showing 20 items per page