|
|
Project:
You will develop and implement a simple system with a GUI front end, a middle business logic layer, and a simple database. The project will be done in 2 phases. The first will have limited functionality, and the second full functionality. The language is Java. The modeling language is UML. UML diagrams can be drawn using MS Visio, which is available in the lab.
The project must be done using basic language features (e.g. Swing classes). There will be no use of canned frameworks, such as WYSIWYG tools for the GUI or data base packages. The data base will be built using basic files.
The deliverables will consist of design documents and code. Most lectures will include a description of one of the deliverables, such as an evaluation of the use of particular pattern in the project.
Project deliverables for each of the two phases are due at the same time, as part of the documentation for that phase, i.e. all of the phase 1 deliverables are due, along with the code, on November 2nd(Tuesday). All of the phase 2 deliverables are due, along with the code, on the last day of class.
The project phases should include clear instructions on how to run the code. The code should be stand-alone, and not require any support environment, other than standard Java libraries, and should be runnable from a command line.
A running example will be used in the lectures. This serves as a guideline to what is expected in your project. From it you can see what each of the deliverables consists of. The example involves a (very) simple dating system. You can use this as your guideline for the project. The point is to try out the basic methods and ideas that are introduced in the lectures. A brief overview of the example is given below:
.There are two classes of users: member and administrator. A user starts the system and logs on, giving a name. The system determines the class of user by looking in a member database. If the user is there, then either a get-a-date or an update-data option can be chosen. If the member is not there, a message is given, and the system returns to its initial state. If the user logs in with a special name, then the system goes into administrator mode, and the following options are given: add-a-member or delete-a-member. If a member is added, the member data in the DB will be empty until the user puts in the data..
. An instance of the member class has properties on the basis of which a date can be selected. In this case they are: gender (M/F) and world view (Spiritual, Secular). The system tries to find an exact match. When a match is found, the email address for the datee is given, which is also stored in the member record in the data base..
.After some function, such as finding a date, the system returns to its initial state, from which the user can start another session (which requires another logon) or terminate the session..
Please provide hard copies of items all items except source and object code.
- Use cases for the whole project (phases 1 and 2):
- Decision as to what use cases or parts of use cases will be implemented in Phase 1.
- Domain model for phase 1:
- System Architecture
- Description of three tier layered system.
- Description of possible use of call-backs and observer/observable pattern in your system.
- Interaction sequence diagrams that show interactions of actors with system, and interactions between subsystems.
- Collaboration diagrams that show how each subsystem responds to a message sent to it. Diagrams required for GUI, Domain Logic, and DB. These are like the diagrams used in the DS project described in class.
- Basic patterns : For each of the expert, creator, and controller patterns, select an example from your project that illustrates the occurrence of the pattern. Show them with collaboration diagrams.
- Class Diagrams : Contains a node for each class for the program. Node has: class name, attributes (class variables), and method signatures. Edges in diagram show object visibility occurrences and associations.
- Code:
- Cd with:
- Source code files.
- Object code classes, stored with their source code files.
Your code should be designed so there is a top level class called Start that has the main() routine in it. You should indicate what command in the command line is needed.
e.g. A:\> java -classpath A:\GiftingSystem Start
- Documentation : You should describe what command could be used to compile your source code files. You should also provide:
- A brief description of how to use your system, including any special GUI features the users should know about.
- A brief description of how the code is organized, such as package/file structures.
- Unit tests : Each class should include a self-test, or have an associated JUnit test class.
- System tests: Describe a set of 3 tests that can be run on the system, with the output that should be expected.
Each phase is worth 15 points for a total of 30 points
The points allocated to each deliverable in phase 1 are as follows:
- (2 points) Use cases for the whole project (phases 1 and 2).
Decision as to what use cases or parts of use cases will be implemented in Phase 1.
The total number of use cases is about 5-10 but can differ for individual projects
- (2 points) Domain model for phase 1
- (1 point) System Architecture
- description of three tier layered system
- description of possible use of call-backs and observer/observable pattern in your system
- this is just what we did in class
- (2 points) Interaction sequence diagrams that show interactions of actors with system, and interactions between subsystems. There will be at least one for each case, maybe more in order to split up different subcases of a use case
- (2 points) Collaboration diagrams that show how each subsystem responds to each message sent to it. Diagrams required for GUI, Domain Logic, and DB. These are like the diagrams used in the DS project described in class. There will be separate diagrams for each message coming into each subsystem. They show how the subsystem will respond to that "message". If you did not implement a DB in phase 1 there will be no collaboration diagrams for it, unless you want to show how it responds to messages with dummy returns for testing purposes, but this is not required..
- (1 point) Basic patterns. For each of the expert, creator, and controller patterns select an example (collaboration diagram) from your project that illustrates the occurrence of the pattern. Show them with collaboration diagrams.
- (2 points) Class Diagrams. Contains a node for each class for the program (phase 1). Node has: class name, attributes (class variables), and method signatures. Edges in diagram show object visibility occurrences and associations.
- (2 points) Code
- (1 point) Documented test cases. We have not done testing yet, so just describe the results of 3 system tests corresponding to different use cases.
- Same as phase 1, but for new functionality. Example:
- Code on CD for whole system.
- Models for new phase 2 functionality: domain models, interaction sequence diagrams, collaboration diagrams, class diagrams (with visibility).
- Include programming by contract specs for subsystems and use is-a and has-a notation in the class diagrams.
- New UML models:
- State diagram model for GUI: graphical or tabular format.
- Programming by contract and testing:
- Dynamic analysis of method contracts (preconditions and postconditions) is done by testing, and the JUnit tests that you have already constructed may be sufficient for testing the inserted pre and postcondition assertions for a couple of methods.
- Static analysis/verification requires reasoning about verification conditions, as discussed in class. The contracts used here could be the same as the ones used in dynamic analysis, or they may be stronger. They may be also written informally, and not necessarily be executable code, simply statements about relationships between variables at the beginnings and ends of a method. If they are the same for your sample methods, that is fine. But testing them, and proving them, are two different things. Testing simply checks them for the tests that were used. Proof/verification/static analysis checks them for all inputs using logical reasoning, in the form of the proofs of the verification conditions.
- Patterns:
- Required use of in project: Factory singleton, wrapper, state and callback (both optional, but discuss why you did not use it if you did not incorporate this pattern), and framework/factory methods for data base.
- Extra credit: For each of the following select an example from your project that illustrates the occurrence of the pattern. If you did not use one of them, discuss how it might have been used, with pros and cons. (Facade, Template, Iterator, Command, Composite, Bridge, Chain, Mediator, Visitor, Memento, Strategy).
- For each pattern that you incorporated into your design, briefly describe how it was used.
- You do not need to include anything on anti-patterns or refactoring.
The points allocated to each deliverable in phase 2 are as follows:
- (2 point) Domain model for phase 2, including generalization and aggregation notation.
- (1 point) Phase 2 Interaction sequence diagrams that show interactions of actors with system, and interactions between subsystems. There will be at least one for each use case, maybe more in order to split up different subcases of a use case.
- (1 point) Phase 2 Collaboration diagrams that show how each subsystem responds to each message sent to it. Diagrams required for GUI, Domain Logic, and DB. These are like the diagrams used in the DS project described in class. There will be separate diagrams for each message coming into each subsystem. They show how the subsystem will respond to that "message". If you did not implement a DB in phase 1 this may be the first place where there will be DB collaboration diagrams.
- (2 points) Patterns
a) Required use of in project. Factory singleton, wrapper, state and callback (both optional, but discuss why you did not use it if you did not incorporate this pattern), and framework/factory methods for data base.
b) Extra credit. For each of the following select an example from your project that illustrates the occurrence of the pattern. If you did not use one of them, discuss how it might have been used, with pros and cons. (Façade, Template, Iterator, Command, Composite, Bridge, Chain, Mediator, Visitor, Memento, Strategy).
- (2 points) Design by Contract.
a) Take 2 class methods, and do a static verification of their contracts, where a contract is an informal pre and post condition. This will require inserting intermediate assertions, and proving the verification conditions. Also do a termination analysis. Follow the examples used in class.
b) Carry out a dynamic verification of those methods, in which you insert executable assertions for pre and post conditions, and then execute the methods over test cases, looking for postcondition assertion violations. Follow the examples in class.
- (1 point) . Phase 2 Class Diagrams. These will contain a node for each new (Phase2) class for the program. Node has: class name, attributes (class variables), and method signatures. Edges in diagram show object visibility occurrences and associations.
- (2 points) State charts or tables for user interface.
- (3 points) Code
- (1 point) Documented test cases. Describe 3 normal system test cases and 3 "oddball" tests. You will probably also have constructed JUnit unit test cases but do not need to include descriptions in deliverables for Phase 2.
|