System Spec, Version 2

In this delivery you should reveal some details on the design of your system. The design should cover the main functionality of the system and include the most important critical details. Obviously, once you implement the system, there may turn up more details. The kitchen timer was an idealized example for this. Each team created decent state machines that documented the important details of the kitchen timer. The subsequent implementation could then focus more on the details how to implement specific actions in Python, but the overall logic was settled.

Use Cases

Use Cases in Table Form

Describe 3 use cases for the major features of your system. Choose use cases at the sea-level. Follow the table format proposed in the book and shown on page 150.

Hints: Most likely, each of the use cases will fit on a single page.

Criteria for the Use Case Part

The main function of the use cases is to provide a clearer picture of the needed system functionality before anything is implemented. The value of this part hence is based on its usefulness for the upcoming process.

	Excellent	Good	Sufficient	Not rateable
Exceptions and Alternatives	Consistent handling of relevant exceptions and alternatives.	Most relevant exceptions and alterntives described.	Some inconsistencies.
Alignment	Consistent with user requirements, vision and system.	Good alignment to the user requirements.	Minor inconsistencies.	Missing alignment.
Descriptions	Concise descriptions.	Use cases have good, descriptive names.		Major language errors and typos.
Value	The use cases provide excellent value for the development by addressing relevant issues in a compact form.	The described use cases form a cohesive, focused whole that are a good basis for planning the upcoming development of the system.	Some value for further development, but inconsistent.

Updated Deployment Diagram

Create an updated deployment diagram of the system.

Take into account what you have learned about components, state machines and communication.
Identify components that include state machines, for instance by using a stereotype «stm».

To demo your system, you will use some GUI elements for user input and control. If you want, and already have a clearer picture about them, you can already represent them in the deployment diagram as well.

Hints:

Usually a deployment diagram should fit on a single page.
Use landscape format if you want.

	Excellent	Good	Sufficient	Not rateable
Layout	Layout follows a strategy that helps to understand the diagram.	Layout is structured.	Layout is structured.	Layout is unstructured and random.
Syntax	Correct syntax.	Correct Syntax.	Overall good syntax, with a few minor errors.	Major syntactical flaws.
Level of Detail	Consistent and intentional level of detail.	Adequate detailing.	Some inconsistencies, too much focus on some details on the expense of others.

Tips for diagram layout
Syntax for deployment diagrams
Level of detail: Details that are included matter, and are not accidental.

Sequence Diagrams

Prepare sequence diagrams for the main use cases of the system. As you have learned in the team activities, it is hard to cover all details on sequence diagrams, and they may lose their value once we make them too complicated or too comprehensive. Therefore, cover the most important scenarios in an effective way. Use fragments (alt, opt,...) where they make sense, but also consider to just cover the same use case with several sequence diagrams that show different scenarios, dependent for instance on important alternatives and exceptions.

The level of detail should be so that it helps you to convey the overall system interactions, help you to create the state machines and uncover critical situations that require clarifications.

How much? Depends of course on your layout. If two diagrams fit on a page, most of your use cases should be covered within 4 pages. Use your own judgment.

	Excellent	Good	Sufficient	Not rateable
Coverage	All relevant scenarios are handled with an appropriate level of detail and clearness.	All relevant scenarios are handled.	Most relevant scenarios are handled.	Important scenarios are missing.
Implied Scenarios	All relevant implied scenarios are handled and clarified.	Some implied scenarios are handled.	No implied scenarios are described.
Combined Fragments	Appropriate use of combined fragments where relevant.		Occasional inappropriate use, that means used where they are not necessary or lack of use where they would help.
Level of Detail	Consistent and intentional level of detail.	Adequate detailing.	Some inconsistencies, too much focus on some details at the expense of others.
Layout	Layout follows a strategy that helps to understand the diagram.	Layout is structured.	Layout is structured.	Layout is unstructured and random.
Syntax	Correct syntax.	Correct Syntax.	Overall good syntax, with a few minor errors.	Major syntactical flaws.

Syntax for interactions.
Pay attention that you select which scenarios to show so that it not only provides coverage, but also helps to understand.
It is, in principle, possible to not use any combined fragments. They should be applied where they help.
If you don't find any implied scenarios, make sure your system is suitable for the course and not overly simplifying reality. If despite this there are no implied scenarios, add a comment.

State Machines

Create state machines for selected components in the system.

State machines must be syntactically correct.
State machines must be complete.
State machines must be implementable in STMPY (in principle), but you don't have to implement them yet.

	Excellent	Good	Sufficient	Not rateable
Control States	Appropriate use of control states that helps to make the machine understandable.	Overall good use of control states.	Overall okay use of control states, with some flaws.	Wrong use of control states. (1)
Events	Explicit and understandable handling of events by correct use of transitions or ''/defer''.	All relevant events are handled in all relevant states.	Most relevant events are handled in most states where they matter.	Major events are not handled.
Semantics	Machine is consistent and critical situations explained in comments.	Machine is free of design flaws.	Some few minor issues.	There are major design errors.
Implementability	Clear how the machine can be implemented in STMPY, ambiguous cases are commented.	Machine is implementable in STMPY.	Machine is apart from a few isolated issues implementable in STMPY.	Machine contains several constructs that are unclear how to implement.
Level of Detail	Consistent and intentional level of detail.	Adequate detailing.	Some inconsistencies, too much focus on some details on the expense of others.
Layout	Layout follows a strategy that helps to understand the diagram.	Layout is structured.	Layout is structured.	Layout is unstructured and random.
Syntax	Correct syntax.	Correct Syntax.	Overall good syntax, with a few minor errors.	Major syntactical flaws.

Syntax for state machines.
A wrong use of control states would be when variables are used to keep track of information that is more suitable for control states. See here.
The state machine should be consistent with respect to states and transition and the requirements. For instance, it does not end up in a deadlocked state or ignore an event unless the requirements are okay with this.

Overall Delivery

At this stage, you should also have a look at the overall quality of the delivery, that means, how the individual parts are connected.

	Excellent	Good	Sufficient	Not rateable
Complexity and scope	The chosen scope for the system is appropriate.			System is too simple to apply learned material.
Consistency	All parts of the delivery are consistent.	Overall good consistency.	Some minor errors with the consistency.	Major inconsistencies between the parts.
Report	Show clear signs of organization and consistency, comments where appropriate.	Generally consistent and organized.	Complete report following the rules for deliveries.	Major flaws in layout and structure.

Feedback Document and Delivery

On Teams, you find a template for the evaluation document, under Semester Project / feedback-v2-team-xx.docx. Create a copy, and fill it out for your own team:

Add team name and team members
Follow the instructions in the document
- For each rubric, evaluate which level you have achieved for each criteria. Comment where necessary.
- Add up to three questions at the end of the document where you ask about particular help.

Delivery

For this week, no individual reflection is necessary, we do it when we have the weekly activity on components.

Deliver both the system specification and the feedback document via Blackboard.