Use Case Meta-Model

Karel van der Walt

©M

enta

lArr

ow -

All

Rig

hts

Res

erve

d 2

of

300

Object vs Meta-language

• ‘This sentence is false’

true/false ?

©M

enta

lArr

ow -

All

Rig

hts

Res

erve

d 3

of

300

Liar’s Paradox

• Paradox arose because we did not , when reasoning about the truth of statements in a language (the object language), use another language in which to reason (the meta language)

©M

enta

lArr

ow -

All

Rig

hts

Res

erve

d 4

of

300

Object vs Meta-language

Therefore A implies C by transitivity

∴∴∴∴A ���� C

B implies CB ���� CA implies BA ���� B

Meta language (natural language) to reason about formulae

Object language of mathematical formulae

©M

enta

lArr

ow -

All

Rig

hts

Res

erve

d 5

of

300

4-Layer Meta-model Architecture

������������

�������������

����������

������������

��������

��

©M

enta

lArr

ow -

All

Rig

hts

Res

erve

d 6

of

300

OMG UML Meta-model

����������� �������� �‘����������’��‘REGISTERED’

�����������������������

��� �� �!�"���

������������������#����������������������

���������������

$������� ������!�� ������

$�������

����������������%��������

�&�$'�

�(���������

���$���������� ���������!�� ����

�)����

����!�"���*�����+��!*

������%��������

&�,���

©M

enta

lArr

ow -

All

Rig

hts

Res

erve

d 7

of

300

W3C XML Meta-model

<Applicant BureauNumber=“B000000013></Applicant>

Instance of Domain Model

M0 User Objects.xml

Applicant, ApplicantStatusInstance of MetaModel

M1 Domain Model.xsd Schema

Entities AttributesInstance of a Meta-MetaModel

M2 MetaModelSchemaOfSchemas

HasFacetAndPropertyXml (reserved attributes and entities)Xsi (reserved attributes)

AxiomsAttribute Schema

M3 Meta-MetaModelhasFacetAndProperty

Level

©M

enta

lArr

ow -

All

Rig

hts

Res

erve

d 8

of

300

Eclipse Model

Say java CodeInstance of Domain Model

M0 User Objects

Instance of MetaModel

M1 Domain ModelEMF Model

Instance of a Meta-MetaModel

M2 MetaModelEMF

EClass EAttributeAxiomsM3 Meta-MetaModelEcore

Level

©M

enta

lArr

ow -

All

Rig

hts

Res

erve

d 9

of

300

Models of computation• Imperative/Procedural

Variables, Assignment statementIterationEg. C-family

• Functional/ApplicativeAbsence of variablesRecursionEg. Lisp-family

• Declarative/LogicalPure whatRecursionEg. Prolog, SQL, XSLT

• Generative/MetaHigher OrderEg. STL

©M

enta

lArr

ow -

All

Rig

hts

Res

erve

d 10

of

300

M0, M1, M2 and computational Models

• Imperative – M0

• Declarative – M0, M1

• Generative – M1, M2

©M

enta

lArr

ow -

All

Rig

hts

Res

erve

d 11

of

300

Model to Meta-Model

©M

enta

lArr

ow -

All

Rig

hts

Res

erve

d 12

of

300

The domain 2b modeled

©M

enta

lArr

ow -

All

Rig

hts

Res

erve

d 13

of

300

Meta-model deficiencies

• OmissionsContext/Boundary, Step/Action

• Absent behaviourClosure, Refactoring, Estimation

©M

enta

lArr

ow -

All

Rig

hts

Res

erve

d 14

of

300

Use Case behaviour

• Use Case refactoring

• Use Case estimation

• Use Case closure

©M

enta

lArr

ow -

All

Rig

hts

Res

erve

d 15

of

300

One systems actor is another system with this system as actor

Registration System

Register for Term

StudentBil ling System

Bill ing System

Bill Student

Student

Registrar

Registration System

©M

enta

lArr

ow -

All

Rig

hts

Res

erve

d 16

of

300

Use Case Points

• Function Points (Albrect)

• Effort/Size

• Duration/Rate of ProgressSchedule

• Gustav Karner 1993 Objectory AB, Rational

©M

enta

lArr

ow -

All

Rig

hts

Res

erve

d 17

of

300� ���������� �����������

� ���� ������ �����

� ���������

� ���� ��� ����� ����� �� ����� � !������

�� ������"�!

� ��#

� ��� ��� ����� ����� �� ����$ ��%�%�%&

' (�#

Size of Context

©M

enta

lArr

ow -

All

Rig

hts

Res

erve

d 18

of

300� ���������� ���� �����

� �������)�������

� ����� �*��* �������*+�* ∈ ,�+�-�

∈ ,�+��'�'�'�'����-

� ���������� ���'��

� ������ ��*���* ��������*+��* ∈ ,�+�-�

∈ ,�+�....����-

Adjusting for Technical & Environmental Complexity

©M

enta

lArr

ow -

All

Rig

hts

Res

erve

d 19

of

300

Technical Factors

…

1End UserT3

2PerformanceT2

2DistributedT1

WeightDescription

©M

enta

lArr

ow -

All

Rig

hts

Res

erve

d 20

of

300

Environmental Factors

…

1OO experienceE3

0.5Application experienceE2

1.5Familiar Development process

E1

WeightDescription

©M

enta

lArr

ow -

All

Rig

hts

Res

erve

d 21

of

300

Duration/Rate of Progress/��0�*%�������� ����� ����������� �����

������ ����������� �����

������ ����������� ����

����� ����

� ���∈ ,���1���+�'��1���-

≈ $��1���

©M

enta

lArr

ow -

All

Rig

hts

Res

erve

d 22

of

300

Use Case Closure

• Span/Cover/BaseCreate all scenarios

©M

enta

lArr

ow -

All

Rig

hts

Res

erve

d 23

of

300

ER model with Temporal Entities

1,1

0,n

0,n 1,1

1,1 0,n 0,n1,1

Patient

SAIDNameSurnameDOBGender

<pi><pi><pi>

A13A35A35DA1

<M><M><M>

MemberPrivate

Dependent

MedicalAid

AidName <pi> A35 <M>

NonDependent

PostalAddressLine1PostalAddressLine2SuburbPostalCodeTitleAccountNr <pi>

A35A35A35A4A4A6

<M>

<M><M>

<M>

<<Temporal>>

Dependence

<<Temporal>>MemberShip

AidNumber A15 <M>

©M

enta

lArr

ow -

All

Rig

hts

Res

erve

d 24

of

300

Object model with Concrete suclasses

1..10..* 0..*1..1

1..10..* 0..*1..1

Patient{abstract}

+++++

SAIDNameSurnameDOBGender

: String: String: String: Date: String

MemberPrivate

Dependent

MedicalAid+ AidName : String

NonDependent{abstract}

++++++

PostalAddressLine1PostalAddressLine2SuburbPostalCodeTitleAccountNr

: String: String: String: String: String: String

Dependence

MemberShip+ AidNumber : String

©M

enta

lArr

ow -

All

Rig

hts

Res

erve

d 25

of

300

STD patientChange Dependence

Change Membership

Gain Membership

Loose Membership

Loose Dependence

Gain Dependence

Gain Dependence

Gain Membership

Private

Dependent

Member

©M

enta

lArr

ow -

All

Rig

hts

Res

erve

d 26

of

300

Simplified

Gain Membership Loose Membership

Loose Dependence

Gain Dependence

Member

Private

Dependent

©M

enta

lArr

ow -

All

Rig

hts

Res

erve

d 27

of

300

Use Case DiagramPractice

<<extend>>

<<extend>> <<extend>>

<<extend>>

<<include>>

<<include>>

MedicalAid

Gain Dependence

Loose Dependence

Loose Membership

Gain Membership

Maintain Patient

Information

Reception

Patient

nonDependent

©M

enta

lArr

ow -

All

Rig

hts

Res

erve

d 28

of

300

Test Cases

Consultation

Gain Membershio Loose Membershio Gain Dependence Loose Dependence

Consultation Consultation Consultation

©M

enta

lArr

ow -

All

Rig

hts

Res

erve

d 29

of

300

Use Case Refactoring

• Small• Behaviour preserving• Inverse

• Relax small, perfect inverse

• Behaviour preservingSize (UCP)Closure

©M

enta

lArr

ow -

All

Rig

hts

Res

erve

d 30

of

300

Use Case Refactoring• Context refactoring :

Partition context with use cases : Fold contexts

• Use Case Refactoring : Steps to included use case : Fold included Use CaseConditional steps to extended Use case : Fold extensionCondition to exception (extension to exception handler) : Exception handler to extension