Software Modeling 2022/23

Project

A major part of the project is the realization of the project of a software system model creation. The project consists of the following parts:

1. Project objective (5 p)
2. Use cases (15 p)
3. Initial behavior model in UML (8 p)
4. Objects, Classes, and interaction (18 p)
5. Components (6 p)
6. Code (8 p)
7. Algebraic specification (5 p)
8. Feature model (non-compulsory part; can compensate at most 5 p)

All parts of the project except for part 8 (feature model) are compulsory. Without submiting them on an acceptable level it is not possible to complete the course.

The maximum number of points for each part of the project is introduced in parentheses. The quality of the work at exercises (readiness, activity, and the level of progress presentation) is an integral part of the project assessment, for which the teacher grants a maximum of 5 points. In total, for the project you can get 70 points. Part 8 can compensate 5 points within the maximum of 70 points.

The projects ends with an individual presentation. For the presentation, a clearly conceived explanation with pointing out the most important parts of the project is expected. During the defense, a correct answering of the teacher's questions is expected. The project presentation and defense can increase or decrease the total project score by up to 30% (the maximum score can't be exceeded).

You are going to make a considerable part of the project in the Enterprise Architect tool (EA). You will add all diagrams into a single project in EA so that they make a consistent whole.

The submission deadlines are introduced in the exercise plan. All parts of the project are to be submitted into the AIS system, for which the corresponding submission sites will be created. Submission sites will be created also for submitting working versions of the project, by which you document an active approach to project realization.

Part 1: Project Objective

>Elaborate the assignments with respect to the general project topic so that it would be clear what software system you are going to model. Provide a corresponding title of your project. Add a description of one use case which you assume to be characteristic for your project to your objective. An expected extent of the project objective is 200–300 words not counting the use case.

Submit the document in the PDF format. Don't forget to include your name.

The project objective is a subject to approval and possible modifications by the teacher. Therefore, make use of the exercises before the deadline to consult the content of its preliminary text.

To be submitted: a document containing the project objective (PDF)

Marking of part 1

The marking is as follows:

• clear and comprehensible intent – 5 p
• mostly clear and comprehensible intent or inappropriate or missing own project title – 4 p
• unclear and incomprehensible intent – 0–3 p

^

Parts 2 and 3: Use Cases and the Initial Behavior Model in UML

Part 2: Use Cases. Create the use case model that corresponds to your project objective. A use case model consists of the textually expressed use cases and the corresponding use case diagrams in UML.

Submit the description of use cases in a separate file (PDF). Prepare the use case diagrams and submit them as a model in EA. The description of use cases must be consistent in a chosen notation: Jacobson's, Cockburn's, or another one, possibly with your own modifications (consult with teachers at exercises). Describe the conventions of the notation that hold for your model.

Take care to have at least one include, one extend, and one generalization relationship between use cases, and to have these among the use cases that have been described (the steps of their flows are stated).

Organize use cases into the diagrams according to the subject. The use case diagrams themselves (not individual use cases) describe directly in EA as if you would be describing the corresponding model. From this description it should be clear why are these use cases introduced together.

Part 3: Initial Behavior Model in UML. Prepare the sequence diagrams for selected use cases (their flows) and for the same use cases also prepare activity diagrams (in order to be able to confront these techniques). Apply the advanced elements of sequence and activity diagrams.

For the use cases for which you worked out sequence and activity diagrams, in the corresponding diagrams, introduce collaborations with roles implied by (the description of) use cases and which occur in sequence diagrams (lifeline types) or in activity diagrams (types of the objects carried over).

To be submitted:

• for part 2 (use cases): a document with the use case description (PDF) and the EA model
• for part 3 (initial behavior model in UML): corresponding diagrams in the EA model

Marking of part 2 (use cases)

For this part of the project to be marked by a nonzero number of points, it must correspond to the assignment and the following conditions must be fulfilled:

1. Use case diagrams must be a part of the EA model.
2. There must be at least six use cases with non-trivial flows described. If use cases of the CRUD type for a given entity are written out into separate use cases, all these use cases are counted as one. In use cases there must be at least one alternative flow apart the extend relationship.
3. The EA model must be submitted in the version whose license is owned by the university.
4. This part must be submitted into AIS and presented at least once at an advanced level of elaboration before its final submission.

The marking of this part of the project is as follows:

• the basic use case model:
• correctly identified and correctly written use cases with introduced and abided of chosen conventions, appropriately organized into use case diagrams according to the subject: 8–9 p
• minor insufficiencies in the use case model, less appropriately organized into diagrams, with unclear identification of conventions or insufficiencies in abiding them: 5–7 p
• major insufficiencies in the use case model, inappropriate or missing organization into diagrams, without explicit identification of conventions or with major insufficiencies in abiding them: 0–4 p
• use case relationships:
• at least one correct include, one extend, and one generalization-specialization relationship between described use cases, consistent with this description: 6 b
• minor insufficiencies in relationships and their consistency with the use case description or without a generalization-specialization: 4–5 b
• major insufficiencies in relationships and their consistency with the use case description or their absence: 0–3 b

Marking of part 3 (initial behavior model in UML)

For this part of the project to be marked by a nonzero number of points, it must correspond to the assignment and the following conditions must be fulfilled:

1. For three use cases (their flows) sequence diagrams must be worked out and for the same three use cases also activity diagrams must be worked out.
2. The EA model must be submitted in the version whose license is owned by the university.
3. This part must be submitted into AIS and presented at least once at an advanced level of elaboration before its final submission.

The marking of this part of the project is as follows:

• correctly conceived sequence diagrams with an appropriate use of combined fragments consistent with the use case description, corresponding activity diagrams with a correct use of decision and connection nodes, correctly introduced collaborations: 7–8 b
• minor insufficiencies in sequence and activity diagrams or a weaker use of combined fragments and decision and connection nodes, minor inconsistency with the use case description, minor insufficiencies in collaborations: 4–6 b
• major insufficiencies in sequence and activity diagrams, including not using combined fragments and decision and connection nodes, substantial inconsistency with the use case description, missing or substantially wrong collaborations: 0–3 b

^

Parts 4–6: Detailed UML Model and Code

Part 4: Classes and Interaction. Depict the classes that make the architectural foundation of the system and the classes identified by the initial behavior model, which resulted from the previous part of the project, in a class diagram as a basic structural model. Take care of the comprehensibility in the sense of appropriate naming and layout of the elements in diagrams. Use several diagrams with an adequate number of elements by which you will capture important system views (one element may occur in several diagrams). Adequately name these views, i.e., class diagrams.

The class identification may be preceded by the identification of the key objects and their relationships by a so-called object diagram. In UML, this diagram is considered only as a special case of a class diagram. Even though it is simple, it bears an advantage of depicting an idea of a functioning system without the necessity to deal with implementation mechanisms. Identify an interesting object configuration and depict it by an object diagram. Depict several variants of fulfilling this configuration by further object diagrams, e.g., before and after their interaction expressed by a sequence diagram, which can help you in identifying states.

Organize classes into packages. Identify dependencies between packages and depict them in a package diagram. The dependencies between the packages have to reflect the dependencies between their elements.

Use sequence diagrams to specify selected methods. Conceive these correctly, including the modeling of the specified method as a found message.

Employ state diagrams to express the state space of the objects of selected classes, system, or system part. Take care of a logical selection of states, correct use of pseudostates, and correct event modeling.

Strive to express the conditions in the model in OCL. A particularly appropriate opportunity is expressing preconditions, postconditions, and invariants at operations.

Part 5: Components. Use component diagrams to express the architecture. Express the component interaction using sequence diagrams. Depict the inner structure and connections of selected components with a composite structure diagram. Capture the main features of the architecture in the programming language of your choice.

Part 6: Code. Introduce the corresponding code for the selected part of the model. Identify and describe the relationship of the code and architecture and use cases.

To be submitted:

• for part 4 (classes and interaction): corresponding diagrams in the EA model
• for part 5 (components): corresponding documents in the EA model
• for part 6 (code): code and document (PDF)

Marking of part 4 (classes and interaction)

For this part of the project to be marked by a nonzero number of points, it must correspond to the assignment and the following conditions must be fulfilled:

1. The EA model must be submitted in the version whose license is owned by the university.
2. This part must be submitted into AIS and presented at least once at an advanced level of elaboration before its final submission.

The marking of this part of the project is as follows:

• correct introduction of classes and interfaces in the model of an appropriate extent (at least 12 elements); introduction of attributes and operations; correct introduction of relationships between classes and interfaces; correctly introduced object diagram and its variants; correctly determined packages and relationships between them with the introduction of the corresponding diagram; consistency of the dependencies between packages with the dependencies between their elements; correctly conceived sequence diagrams of at least two selected operations consistent with the meaning of the modeled operations, of a non-trivial complexity, and with an appropriate use of combined fragments; at least two correct state diagrams; at least one correct OCL expression; introduction of an appropriate element description (directly in the model): 17–18 p
• minor insufficiencies such as a repeated aggregation by attributes, not using interfaces and similar; missing object diagram variants; errors in package diagrams, omitting the inclusion of classes and interfaces in packages in the model or their introduction only on the level of a diagram, or an inconsistency between the dependencies between packages and the dependencies between their elements; insufficiencies in sequence diagrams, inconsistency with the meaning of the modeled operations, or oversimplified sequence diagrams; insufficiencies in the logic of state selection or in introduction of events: 9–16 p
• major insufficiencies: 0–8 p

Marking of part 5 (components)

For this part of the project to be marked by a nonzero number of points, it must correspond to the assignment and the following conditions must be fulfilled:

1. The EA model must be submitted in the version whose license is owned by the university.
2. This part must be submitted into AIS and presented at least once at an advanced level of elaboration before its final submission.

The marking of this part of the project is as follows:

• appropriate component diagram and composite structure diagram with correctly introduced dependencies between components; introduction of an appropriate element description: 6 p
• insufficiencies in component diagram and composite structure diagram: 4–5 p
• major insufficiencies: 0–3 p

Marking of part 6 (code)

For this part of the project to be marked by a nonzero number of points, it must correspond to the assignment and the following conditions must be fulfilled:

1. The code can be executed.
2. A description is provided with the code.

The marking of this part of the project is as follows:

• appropriate code with a clearly described relationship to the architecture and use cases: 7–8 p
• less appropriate code or less clear description: 5–6 p
• major insufficiencies: 0–4 p

^

Part 7: Algebraic Specification

Use an algebraic specification to express a chosen class from your model. Express the specification in a separate text file. Mark clearly all four parts of an algebraic specification: types, functions, axioms, and preconditions. Take care to introduce all relevant functions and axioms. Briefly explain your specification.

To be submitted: a document with an algebraic specification (PDF)

The marking of this part of the project is as follows:

• correct algebraic specification of a non-trivial class with at least three operations: 5 p
• minors mistakes in the algebraic specification: 3–4 p
• major mistakes in the algebraic specification or opting for a trivial class: 0–2 p

Part 8 (non-compulsory): Feature Modeling

Capture the variance of a selected part of your system by a feature model. The expected extent is about ten features. The feature model is to be submitted as a separate PDF document.

Introduce the feature model as one or several feature diagrams with appropriate additional constraints expressed as text. Describe briefly each feature (one sentence is sufficient) so that it is clear what does it represent.

Relate variable features to corresponding elements or parts of the model being configured.

• a feature model that adequately expresses variance with an adequately specified relationship between the features and the model being configured with an appropriate description of the features – 5 b
• a feature model that mainly adequately expresses variance with a mainly adequately specified relationship between the features and the model being configured with an appropriate description of the features – 3–4 b
• a feature model that less adequately expresses variance with a less adequately specified relationship between the features and the model being configured with an weaker description of the features – 0–2 b

^