The “Design and Analysis of Information Systems” course is devoted to practising the skills that are necessary for transition from a conceptual model (the product of the analysis and requirements specification phase in software development life cycle) into a specific implementation environment, either object-oriented or relational. Students learn some conceptual features that have no direct counterparts in a chosen implementation environment (actually Java or MS C#). Some rules regarding designing (usability) and implementing user interfaces and utilization of software frameworks are also presented. The lectures are supported by the implementation including data management, application’s behaviour and creating simple GUIs. Requirement specification and static analysis should be done along with teaching the course “Object Modelling Techniques in Software Analysis” (PRI). The size of a project, that each student has to do on their own, is limited to between 10 and 15 UML classes.
|1||Designing and Modeling of System Architecture||· A brief discussion of the subject and the objectives of the project.
· Exercises of dynamic analysis.
· Class involves drawing diagrams on the basis of the requirements. You can use the dedicated CASE tool or traditional whiteboard.
|2||Selected Constructs of Object-oriented Programming Languages||Exercising of the selected constructs of object- oriented programming language.
Class involves creating programs using various designs. The nature and scope is defined by level of the group (which is determined by the teacher) and can be based on the contents of the lecture.
|3||Selected Constructs of Object-oriented Programming Languages (2)||Exercising of the selected constructs of object- oriented programming language.|
|4||Using Classes in Object- oriented Programming Languages||Exercising with the use of classes in object- oriented programming languages.|
|5||Associations in Object- oriented Programming Languages||· Exercising of implementing association in object-oriented programming languages (1).
· Evaluation of the mini project MP1
(lecture material for classes)
|6||Associations in Object- oriented Programming Languages (2)||Exercising of implementing association in object-oriented programming languages (2).|
|7||Inheritance in Object- oriented Programming Languages||· Exercising the implementation of different models of inheritance in object-oriented programming languages.
· Evaluation of a mini project MP2 (lecture material for associations)
|8||Implementation of Other UML Constructs in Object- oriented Programming Languages||· Exercising the implementation of various UML structures in object-oriented programming languages.
· Evaluation of a mini project MP3 (lecture material for inheritance)
|9||Relational Model in Object- oriented Programming Languages||· Evaluation of a mini project MP4 (lecture material for constraints)
· Exercising the implementation of the relational model in object-oriented programming languages
|10||Relational Model in Object- oriented Programming Languages (2)||· Exercising the implementation of the relational model in object-oriented programming languages|
|11||Usability of Graphical User Interfaces||· Evaluation of a mini project MP5 (lecture material for relational model)
· Work on the final project.
|12||Design and Implementation of Graphical User Interfaces||· Exercising the implementation of graphical user interfaces (including the use of a dedicated GUI editor).
· Work on the final project.
|13||Design and Implementation of Graphical User Interfaces (2)||· Exercising the implementation of graphical user interfaces (including the use of a dedicated GUI editor).
· Work on the final project.
· The deadline for sending documentation. There is no possibility of sending the documentation later.
|Evaluation of final project implementation.|
|Graphical User Interfaces (3)|
|15||Design and Implementation of Graphical User Interfaces (4)||All matters relating to the final evaluation of the classes.|
Their goal is to test the understanding the practical ways to implement particular constructions of the conceptual model (classes, associations, an extent, etc.) and their cooperation with the relational model. In addition, they can be treated as a “cornerstone” of the final project (which later will be supplemented with other required elements, e. g. GUI). You need to implement various business constructs (all the technical information such as the number of objects in extent, setters / getters do not apply), which are present in the conceptual model. Every MP must contain examples of data and / or methods that illustrates its proper operation (localized in the main() method). Projects evaluation schedule – see attached classes schedule. During the evaluation you can expect questions about ongoing issues and implementation approaches. Your late mini projects can be evaluated during next classes, but it is associated with a 50% reduction in the score.
MP elements to be assessed1:
|· A class extent
· A class extent – persistence
· A complex attribute
· An optional attribute
· A multi-value attribute
· A class attribute
· A derrived attribute
· A class method
· Method overriding and overloading
· With an attribute
In every case: cardinality 1-* or *-* and automatic creation of a reverse connection.
|· An abstract class and polymorphic method invocation
· An overlapping inheritance
· A multi-inheritance
· A multi-aspect inheritance
· A dynamic inheritance
|· For an attribute
· Custom business constraint
|· RM – classes
· RM – associations (1-* or *-*)
· RM – inheritance.
You should create a program that uses a database and implements the above structures. You can use any tools,
e.g. ORM-s, for example: Hibernate, Entity Framework.
The topics of the MPx could be different from a topic of the final project.
1 You should propose your own business cases, i. e. do not use examples from lectures, books, etc.
2 Relational model (MR) is not applicable for students of Department of Information Management (WZI).
It is not allowed to combine different constructs in the same example, e.g. each kind of an attribute should have its own business example.
Mini-projects are an integral part of the final evaluation (see section 5.1). Thus they should be well prepared.
- The final project consists of two parts: a documentation and an implementation. Its topic should be complex enough to create the appropriate number (12 – 15) meaningful business classes. Because of this, topics like tool applications, system applications, media players, etc. are not suitable. If you have doubts you should consult the
- The documentation includes the “old” part, e. the one that has been created on the PRI class (included as an attachment) and the “new” documentation. The “new” documentation copies the “old” documentation scheme, but there are some new elements, which are mentioned below. Those who do not have the “old” project of the PRI must develop at least: requirements (as the “story”), the use case diagram and analytical class diagram.
- Use cases: „New” documentation of use cases should include detailed description of one non-trivial use case in addition to “old” documentation. The use case should refer to another use case. The scenario for this use case should be made using both natural language and activity
- User interface design: based on the selected non-trivial use case, user interface design should be made (according to the guidelines given in the lecture).
- For selected use case a dynamic analysis should be performed (i.e., UML diagrams of activity, interaction and state should be provided). Dynamic analysis should be completed not only by the appearance of the methods in the class diagram, but also a discussion of its implications. “The effects” of the dynamic analysis (perhaps not only new methods, but also new attributes, new associations, etc.) should be placed on a class diagram redrawn from the “old” project and, where possible, highlighted with a different color. The project must use all the kinds of diagrams mentioned
- Before the “final” class diagram, which forms the basis for implementation, it is necessary to include elements specifying the design decisions (for example, based on the relevant parts of the diagram), e.g. how to implement a class extent.
- In summary, the “final” (design) class diagram differs from the diagram provided on the PRI in the following sections:
- Has more details
- All structures which do not exist in a given programming language are transformed (according to the design decisions)
- Is supplemented with methods resulting from dynamic analysis
- You should take care of the readability of the entire documentation, especially diagrams (some vector format is recommended, e. g. Enhanced Metafile). Hence, you should ensure that:
- each of them is properly described/entitled,
- diagrams are prepared in a suitable tool (e. g. UMLet),
- you use fonts which are big enough (100% A4 view should be readable),
- layout is clear, e.g. draw inheritance as vertical lines and associations as horizontal ones, avoid crossing lines,
- Documentation should be delivered in a single PDF file (pdf) sent to the email address of the teacher. Deadline – see the attached schedule.
- A summary of the contents of the project documentation (PRI + MAS):
- User requirements
- The use case diagram
- The class diagram – analytical
- The class diagram – design
- The scenario of selected use case (as text)
- The activity diagram for picked use case
- The state diagram for selected class
- The interaction (sequence) diagram for selected use case
- The GUI design
- The discussion of design decisions and the effect of dynamic analysis
- The evaluation of the documentation will be issued in accordance with the table below (prerequisite: meeting the requirements of paragraph 1):
|The complexity of the business domain||10|
|Documenting the use case(s) (scenario and diagram)||10|
|Correctness and complexity of the design class diagram||25|
|Correctness and complexity of the interaction diagram||10|
|Correctness and complexity of the activity diagram||10|
|Correctness and complexity of the state diagram||10|
|The GUI design||10|
|Discussion of the design decisions||10|
|Readability and organization of the document||5|
- The whole structure (all the classes with appropriate associations).
- Methods required to implement the use case (or cases).
- Elements of the graphical user interface (GUI), which are necessary to present a working implementation of the selected use case. Each project must have a
- Minimum implementation of the GUI use case should involve an interaction of two classes connected with an association, for example: We have two
classes: an Employee and a Company; a widget (capable of showing many items, e.g. ListBox) contains a list of companies, after clicking on any item should cause display another widget (capable of showing many items, e.g. ListBox) which contains a list of its employees retrieved using a defined association. GUI implementation, which only creates connections between objects and does not allow for the above interaction, is not enough to pass the project. Similarly, solutions e.g. with a single widget, a TextBox or just filtering the extent are insufficient (instead of using a previously defined association).
- Pay attention to quality, ergonomics and usability of GUI (e.g., windows scaling, colors, philosophy of actions) – it is an important component of the final assessment. Design and implementation of GUI (you can use dedicated editors) shall be in accordance with the principles of usability, described at the lecture.
- All data stored in the system must be persistent (e.g. file, database, dedicated library, ).
- Implementation of the project will be individually evaluated during the exercises (see below). Therefore, it does not need to be send in any persistent form.
- Language of the implementation can be Java, C# or C++. Other languages should be agreed with the
- The grade for the implementation will be issued in accordance with the following table (prerequisite: meeting the requirements of Section. 2):
|Difficulty of the task||10|
|The scope and the correctness of the realized functionality||15|
|The scope and correctness of completed object-oriented constructs||25|
|Code quality (names, comments, JavaDoc, etc.)||5|
|The elegance of implemented solutions||15|
|The way of the persistence implementation||10|
|The implementation of the GUI (including usability/ ergonomics)||20|
The final project does not have to include all constructs from mini-projects.
- Each project will be evaluated individually. During the evaluation, you can expect detailed questions about the way of the implementation, e. g. “What will be if…”, “Why it’s done this way…”, “Please make the following ..”. People who
implemented the projects personally should not have any problems with answering the above questions. Lack of ability to answer above questions will result in negative grade of the classes.
- The following aspects of the project will be evaluated (see also points Błąd! Nie można odnaleźć źródła odwołania., Błąd! Nie można odnaleźć źródła odwołania.):
- The difficulty of the
- The realized scope of the
- The documentation of the code including the comments, that allows to automatically generate API
- The elegance of implemented solutions, including the GUI ergonomics
- The credit of the exercises
Final evaluation of the exercise consists of the following components:
- Points for mini-projects (total sum – no need to individually classify each item): 20 + 20 + 20 + 16 + 24 = 100 ,
- Evaluation of the project:
- Grade for the implementation
- Grade for the documentation
Additionally, you can earn up to 15 points for solving tasks described during lectures. These bonus points are added to the total number of points (see Para. 5.1), provided you have at least 50% of the points.
Deadlines for the various tasks (mini-projects, final project documentation, and implementation of the final project) are given in the table (point 2). Exceeding deadlines will result serious reduction in the mark, including up to failing the exercises.