Optional - Modelleringsprinciper

Question 1

Beskriv vilka begrepp och notation som gäller för UML Use Case Diagrams!

Answer 1

• Actor
  “… roles that people, other systems or devices take when communicating with a particular use case or use cases”
• Use Case
  “…describes a sequence of actions that the system performs to achieve an observable result of value to an actor.” – can be seen as function that a stakeholder (actor) needs.
• System boundary
  “… depicts the use cases being inside the system or sub-system, and the actors being outside the system.”
• Relationships
  1. Actor – Use Case: communication association
  2. Use case dependencies:
  a) Extend – used when the behaviour of a use case is (optionally) extended by another use case.
  b) Include – used when a use case always incorporates the behaviour of another use case.
  c) Generalization – used when a use case inherits behaviour of a parent use case.

Question 2

Beskriv vilka begrepp och notation som gäller för UML Use Case Descriptions!

Answer 2

Två typer:
- Single paragraph (a bit similar to user stories)
Exempel:
Use Case: Process sale
The cashier starts a new sale and enters all products. The system shows the total amount. Once the customer selects the payment, perform use case “Handle Payment”. Customer may choose to temporary suspend a sale. If the item is discounted or the customer indicated a discount perform use case “Handle discount”.
- Two column style – one column for actiors actions and one for systems response.

Full Description:
Use Case Name – Start with a verb
Scope – System under design
Primary Actor – Calls on the system to satisfy its goal (does not necessarily trigger the use case)
Supporting actor – Provides a service to the system under discussion, aka “secondary actor”
Pre-conditions – What must be satisfied on start
Post-conditions – What must be true on successful completion.
Main/Basic flow of events – The main success scenario path
Alternative flows – Alternative and exception scenarios
Extension points – Possible extensions of the use case (“extend” pattern)

Question 3

beskriv vilka begrepp och notation som gäller för System Sequence Diagrams

Answer 3

• UML System Sequence Diagrams are used to depict input and output events fo/from the system
• As such they can be combined with the textual description, or replace it.
• Major diagram elements:
  o Objects
  o Messages
• One sequenced diagram is created for every system use case. The model shows the events I a time ordering.

Question 4

Beskriv vilka begrepp och notation som gäller för Domänmodeller!

Answer 4

• A domain model documents the information concepts from the problem domain. E.g. Person, customer, payment, order.
• Identification of classes in the domain model. Analysing the requirements sources and use case descriptions.
• A domain model should not contain software classes and other information system design artefacts. The latter are part of information system design. A domain model can later be elaborated into a design class diagram as part of the system design task.
• A domain model describes the static aspect of the domain. The dynamic aspects are addressed by business process models and use cases.
  Some domain modelling constructs to remember
• Generalization – specialization
• Properties specialization
  o Inheritance – subclasses inherit attributes and operations from super-classes.
  o Transitive operation of inheritance – sub-classes inherit from their super-classes all the way to the top of the hierarchy.
  o Disjoint nature of generalization hierarchies – instance of subclasses of the same generalization hierarchy can not overlap.
• Liskov Substitution Principle (LSP)
  o You must be able to substitute any object for its base type.
  o “If it looks like a duck, quacks like a duck, but needs batteries you probably have the wrong abstraction.”
• Composition and aggregation
• Description classes- separate information and thing
• Powertypes – represent types of information and things

Question 5

Vilka generella problem stöter vi på inom modellering?

Answer 5

• Relationships among use cases are not supposed to show the order in which they are performed.
• Use cases are interactions between the user and the system. That is, there should not be purely manual activities as use cases or atomic use cases that are steps of something larger.
• CRUD – information needs to be Created, Read, Updated and Deleted and we need use cases to do this. Unless things “just happen” purely automatically.
• Use case should be about the system we’re building, and not about some other external system. External systems are actors.
• Naming of use-cases – an active verb and a noun phrase.
• Too large, too small… remember the granularity tests from OOS… E.g. the boss test.