1. Design Class Diagram
Milestone 5 (Deliverable 8.1) (Design Class Diagram (DCD))
The team describes the software used to complete the diagram.
The team uses a rectangle with three compartments to represent classes. The name compartment (1st compartment) includes the stereotype name, class name, and superclass name (if any).
Stereotypes including an entity class, a boundary or view class, a controller class, and a data access class are placed within printer’s guillemets, like this: «control» pg. 376.
The lower two compartments contain more details about the attributes and the methods.
Second Compartment
Attributes: visiblity attribute-name: data-type-expression = initial-value {property}
Visibility: “+” = public/visible, “-” = private/invisible
Attribute name
Data-type-expression (such as character, string, integer, number, currency, or date)
Initial-value, if applicable
Property (within curly braces), such as {key}, if applicable
Third Compartment
Method signatures: visiblity method-name (parameter-list): return-type-expression
Interacting objects/classes are connected by navigation visibility arrows. One-to-many associations that indicate a superior/subordinate relationship are usually navigated from the superior to the subordinate. Mandatory associations are usually navigated from the independent class to the dependent class. Navigation visibility arrows may be bidirectional
The diagram is neat, free of spelling errors, and professional quality explained, labeled, and legible (without zooming).
The team develops a design class diagram encompassing domain classes, including controller class | handlers and attributes to represent ALL use cases.
2. Sequence Diagram with View and Data Access Layers
Milestone 5 (Deliverable 8.2) (Sequence Diagram with View and Data Access Layers)
The team describes the software used to complete the diagram.
The team describes the software used to complete the diagram.
The team uses a stick figure to represent an actor who interacts with the system.
The team represents lifelines for the actor and system using a dashed line pg. 409
The team uses boxes to represent instantiated objects from the corresponding classes
The team represents activation lifelines with vertical boxes on each lifeline
The team’s diagram has a :System object with simply a rectangle with the name of the object underlined
The team uses a solid arrow between the lifelines to represent the messages that are sent by the actor. AND Messages/commands are labeled to describe their purpose AND the input data in the message is in parenthesis
A dashed arrow is used to indicate a response or an answer from the system below the initiating message. The response is labeled with information returned.
The team represents return assignment with the “:=” operator
The team represents the same message sent multiple times in a loop. The term uses a loop frame. The loop frame indicates a loop condition with a small rectangle.
An exemplary project has an opt frame or an alt frame when possible pg. 142
The team uses a view object for each input message or form or screen. It is represented by a rectangle with a colon, the name of the object underlined, and the > notation underlined. The activation lifeline is a vertical box below each view object
The team uses a > object for each input message to write itself to the database and read to retrieve data in the database. It is represented by a rectangle with a colon, the name of the object underlined, and “DA” added to the name. Each data access object has a lifeline
The diagram is neat, free of spelling errors, and professional quality explained, labeled, and legible (without zooming).
The team creates a SSD with view and data access layers for ALL fully developed use cases.
3. Package Diagram
Milestone 5 (Deliverable 8.3) (Package Diagram)
The team describes the software used to complete the diagram.
The package diagram has three layers, view layer, domain layer, and data access layer.
The classes are placed inside the appropriate package based on the layer to which they belong.
The team uses a dashed arrow to represents a dependency relationship. The arrow’s tail is connected to the package that is dependent, and the arrowhead is connected to the independent package.
The diagram is neat, free of spelling errors, and professional quality explained, labeled, and legible (without zooming).
The team creates a package diagram with all views, domain classes, including controller class | handlers, and data access for ALL fully developed use cases.
————————————————————————————————–
So, I need three diagrams, and I will provide all the related files. The word file has most of the Project info to base the diagrams.
