ERD DesginReview

ERD Module Design Specifications, Review Page


Posted By : Wessam Abdrabo



This page is used to manage the review of the ERD Module Deisgn Specification.

The value of this approach is that it allows us to track each issue separately and drive them to resolution. The document can be considered approved when all comments are marked as Approved.

The review process works like this:

  • Add a comment header of the format
    "<initials>-<number> - <description> (<status>)"
    (see below for examples)
  • A discussion then can take place under that comment header
  • Each comment will have a status at the top, with the status set to Approved, Accepted PDU (pending doc update) or Unresolved. If a comment has no status, it is assumed to be unresolved.
  • If necessary, we do more rounds of discussion until the item is marked as Approved
  • There may be some items which can not be resolved through this means. If that happens, we may arrange a meeting (perhaps on an IRC channel) to try and work through the remaining open issues.

Commenter Initials Key

DVC01 - Dependency on DB to DB Explorer

This all looks good except that you don't explain the meaning of the arrow. Does this mean a dependency? If so, it's not right that the database depends upon the DB Explorer API. Rather, the DB Explorer API depends upon the database.

Other than that, this diagram looks quite good.

What I'd want next are the following:

  • A description of each subsystem - it's role, some of its key features, and any issues around that component
  • A description of how these subsystems interact as you exercise each use case. For example:

Use Case: Create New Entity

  • User drags entity component from pallette onto E/R model
  • An entity widget is created in the Visual Library
  • User modifies the properties of the entity component
  • These changes are stored in the model and in the background written out to the XML representation

I'm just guessing, but something like that is needed

Also, when you describe these subsystems, it would be very good to go into detail where it makes sense. What are the high-level components within these subsystems? As it stands, this document is a little too high-level. It's a good introduction, but we need a little bit more. Think of yourself as someone from the outside trying to understand how this all works - wouldn't you want a little bit more?

Thanks!

David

DVC02

Hi, Wessam. When responding to a comment, please do it underneath the header for that comment, rather than creating a new header...

Trey's comments reflected something that was concerning me, too. In particular, we may want to be able to generate DDL from a schema without having to create an E/R diagram first (some users may want to general the SQL DDL but may not want to bother with an E/R diagram).

As it currently stands, you go straight from DB Explorer to visual library, and there is no way to go from DB Explorer to DDLUtils without going through the Visual Library... If DB Explorer went to Data Model, then we could achieve the use case above. That's in line with TS01.

WGA01- Dependency on db explorer

Maybe the diagram is not very clear. The arrows mainly represent the dataflow along the different components. It was not meant to show dependency of one component on the other. We might change that to connectors and not arrows to avoid confusion.

The arrow from the database to DB Explorer shows how the reverse mechanism is performed. DB Explorer is utilized to connnect to the database and grab the metadata, then Visual Library is used to create the visual representations of tables, columns, indexes and so forth. We adopted this mechanism form a tutorial by Anton Epple and we're planning to change it to suite our needs. So mainly the arrow doesn't mean dependency, it just shows the flow of data.

For the forward part (genrating tables set and SQLs form ER Diagram) , DDLutils is utitlized. do you think it's better that we unifrom how we do things in both directions? or as long as it goes for us, then there's no probelm?

WGA02- Is a GUI Component Missing ?

We got feedback that this diagram lacks a module to show how input gets into the system. So we thought of adding a "Designer" or "GUI" component that can contain for example: Diagram Editor, Component Palette, Properties Window as subcomponents. This component would be connected to Visual Library and datamodel.

Is this needed?

David: Yes, I tink

(TS) I think that I would rather see a use case document. The use case document should show the use cases in the system, and a flow of how to use cases are to be handled.

David: I agree, a use case document is needed, that's what I asked for too. I would consider that an addendum to this document, rather than a separate one.

WGA03- What else can a Datamodel be called?

What we mean by the Datamodel Component is the instances of the datamodel classes that hold the data (at runtime) of the diagram that is basically needed to generate XML (using Simple Framework). However, the term didn't convey this meaning to some of the reviewers. What else can we call it to mean that?

Why not just call it the "model", not to confuse it with the Database metadata

Also, is it valid to put this component in the architecture?

TS01 - Reverse Engineering Data Flow

The diagram shows that the data flows as database->Database Explorer API->Visual Library. Instead the data should flow from the Database Explorer API to the data model.

David: I agree, the Visual Library subsystem should only get its information from the data model

TS02 - Model Persistence

Is the XML Serializer going to be used to persist the model data, or is it only going to be used to transform the model into the DDLUtils input file? If the XML Serializer is also going to be used to persist the data model, you may want to put a arrow from the XML Serializer to the Data Model as well. If the XML Serializer is not going to be used to persist the data model, how do you intend to persist the data model?

David: I think the data model is an in-memory representation of the model. I think what I'd rather see is that the XML Serializer flows both to DDLUtils and to a flat file.

This is a good question: how is the ER diagram going to be persisted? Will it be stored in native DDLUtils format, or another format? Describing the use cases would help clarify some of this.

Youmna: that is what we thought to do. we thought to persist the ERD using the DDLUtils XML format. We thought also to have another XML file to store the visual info of the diagram, like the widgets locations on the scene, sizes...and any other visual attributes we need to store about the scene

Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo