Class diagram

It depicts a start at a simple UML class diagram for the conceptual model for the university. Classes are depicted as boxes with three sections, the top one indicates the name of the class, the middle one lists the attributes of the class, and the third one lists the methods. By including both an attribute and a method box in the class we are making design decisions in my model, Inheritance hierarchy. Many similarities occur between the Student and Professor classes. Not only do they have similar attributes, but they also have similar methods. To take advantage of these similarities,we created a new class called Person and had both Student and Professor inherit from it, as we see in Inheritance Relationship. This structure would be called the Person inheritance hierarchy because Person is its root class. The Person class is abstract: objects are not created directly from it, and it captures the similarities between the students and professors. Abstract classes are modeled with their names in italics, as opposed to concrete classes, classes from which objects are instantiated, whose names are in normal text. Both classes had a name, e-mail address, and phone number, so these attributes were moved into Person. By introducing this inheritance relationship to the model, we reduced the amount of work to be performed. Instead of implementing these responsibilities twice, they are implemented once, in the Person class, and reused by Student and Professor. Taxanomy of classes Taxonomies are classifications of entity types into hierarchies, There are several interesting aspects

It takes a single section approach to classes, instead of the three section approach, because were exploring relationships between entity types but not their responsibilities. There are three generalization sets for Person: Nationality, Role, and Gender. These generalization sets overlap a person can be classified via each of these roles (e.g. someone can be a male foreign student). This is called multiple classification. We can indicate sub generalization sets, for example Student within the Role generalization set.

Use Case Template

Name: Enroll in Seminar Identifier: UC 1 Description: Enroll an existing student in a seminar for which he/she is eligible. Preconditions: The Student is registered at the University. Postconditions: The Student will be enrolled in the course he wants if he is eligible and room is available. Basic Course of Action: 1. 2. The use case begins when a student wants to enroll in a seminar. The student inputs her name and student number into the system via Security Login Screen. The system verifies the student is eligible to enroll in seminars at the university according to business rule Determine Eligibility to Enroll. [Alt Course A] The system displays Seminar Selection Screen, which indicates the list of available seminars. The student indicates the seminar in which he wants to enroll. [Alt Course B: The Student Decides Not to Enroll] The system validates the student is eligible to enroll in the seminar according to the business rule Determine Student Eligibility to Enroll in a Seminar. [Alt Course C] The system validates the seminar fits into the existing schedule of the student according to the business rule Validate Student Seminar Schedule. The system calculates the fees for the seminar based on the fee published in the course catalog, applicable student fees, and applicable taxes. Apply business rules Calculate Student Fees and Calculate Taxes for Seminar. The system displays the fees via Display Seminar Fees Screen. The system asks the student if he still wants to enroll in the seminar. The student indicates he wants to enroll in the seminar.

3.

4.

5.

6.

7.

8.

9. 10. 11.

12. 13.

The system enrolls the student in the seminar. The system informs the student the enrollment was successful via Seminar Enrollment Summary Screen. The system bills the student for the seminar, according to business rule Bill Student for Seminar. The system asks the student if he wants a printed statement of the enrollment. The student indicates he wants a printed statement. The system prints the enrollment statement Enrollment Summary Report. The use case ends when the student takes the printed statement.

14.

15. 16. 17. 18.

Alternate Course A: The Student is Not Eligible to Enroll in Seminars. A.3. The registrar determines the student is not eligible to enroll in seminars. A.4. The registrar informs the student he is not eligible to enroll. A.5. The use case ends. Alternate Course B: The Student Decides Not to Enroll in an Available Seminar B.5. The student views the list of seminars and does not see one in which he wants to enroll. B.6. The use case ends. Alternate Course C: The Student Does Not Have the Prerequisites C.6. The registrar determines the student is not eligible to enroll in the seminar he chose. C.7. The registrar informs the student he does not have the prerequisites. C.8. The registrar informs the student of the prerequisites he needs. C.9. The use case continues at Step 4 in the basic course of action.

Data Flow Diagram

In the late 1970s data-flow diagrams (DFDs) were introduced and popularized for structured analysis and design (Gane and Sarson 1979). DFDs show the flow of data from external entities into the system, showed how the data moved from one process to another, as well as its logical storage. DFD we have designed uses the Gane and Sarson notation. There are only four symbols: 1. Squares representing external entities, which are sources or destinations of data. Eg:- Applicant 2. Rounded rectangles representing processes, which take data as input, do something to it, and output it. Eg: - Inspect Forms 3. Arrows representing the data flows, which can either be electronic data or physical items. 4. Open-ended rectangles representing data stores, including electronic stores such as databases or XML files and physical stores such as or filing cabinets or stacks of paper. Eg:- Student database In this case we started with the applicant, the external entity in the top left corner, and simply followed the flow of data throughout the system. We introduced the Inspect Forms process to encapsulate the initial validation steps. We assigned this process identifier 1, indicating that its the first process one the top level diagram. We also indicated who/what does the work in the bottom section of the process bubble, in this case the registrar. You can see how the improperly filled out forms are returned to the applicant if required. The second process encapsulates the logic for creating a student record, including the act of checking to see it the person is eligible to enroll as well as if theyre already in the database. The Collect Fees process interacts with an electronic data store, Financial DB, as well as a physical one, Cash Drawer.

Deployment diagram for the student administration application is as shown in figure. The three-dimensional boxes represent nodes, either software or hardware. Physical nodes should be labeled with the stereotype device, to indicate that its a physical device such as a computer or switch. We didnt indicate that WebServer is a device it will at least be some sort of software artifact and very well may be one or more physical devices as well but my team hasnt made that decision yet. Connections between nodes are represented with simple lines, and are assigned stereotypes such as RMI and message bus to indicate the type of connection. The ApplicationServer node contains EJBContainer (a software node) which in turn contains three software components, a deployment specification, and a software artifact. The software components use the same notation as component diagrams. Deployment specifications are basically configuration files, such as an EJB deployment descriptor, which define how a node should operate. They are depicted as two-sectioned rectangles with the stereotype deployment spec, the top box indicates the name and the bottom box lists the deployment properties for the node. Software artifacts are shown with the visual stereotype of a page with a folded corner or with the textual stereotype artifact

We have drawn the UML sequence diagram for the basic course of action for the Enroll in Seminar use case. This is an alternative way for modeling the logic of a usage scenario, instead of doing it at the system-level Messages are indicated on UML sequence diagrams as labeled arrows, when the source and target of a message is an object or class the label is the signature of the method invoked in response to the message. However, if either the source or target is a human actor, then the message is labeled with brief text describing the information being communicated. For example, in the EnrollInSeminar object sends the message isEligibleToEnroll(theStudent) to the instance of Seminar. The Student actor provides information to the SecurityLogon object via the messages labeled name and student number (these really arent messages, they are actually user interactions). Return values are optionally indicated using a dashed arrow with a label indicating the return value. For example, the return value theStudent is indicated coming back from the Student class as the result of invoking a message, whereas no return value is indicated as the result of sending the message isEligibleToEnroll(theStudent) to Seminar. We used a UML note; notes are basically free-form text that can be placed on any UML diagram, to provide a header for the diagram ,indicating its title and identifier the qualifications() message likely represents a series of messages sent to the student object. Common UML practice is to anchor a note to another model element with a dashed line when appropriate, in this case the note is attached to the message.

In the State Machine Diagram,The rounded rectangles represent states: you see that instances of Seminar can be in the Proposed, Scheduled, Open For Enrollment, Full, and Closed to Enrollment states. An object starts in an initial state, represented by the closed circle, and can end up in a final state, represented by the bordered circle. The arrows represent transitions, progressions from one state to another. For example, when a seminar is in the Scheduled state, it can either be opened for enrollment or cancelled. The notation for the labels on transitions is in the format event [guard][/method list]. Guard, conditions that must be true for the transition to be triggered, are optionally indicated. The [not seat available] guard is shown on the student enrolled transition from the Open For Enrollment to the Closed To Enrollment state.