This presentation covers moving towards implementation, from requirements to code, controlling inheritance, using tools to automate development, and modeling implementation and deployment.

1. Arab Open University
2nd
Semester, 2006-2007
M301
Unit 5.1
From Model to
Implementation
reem.attas@arabou.org.sa

2. Reem AlAttas © 2
Topic Road Map
 Moving towards Implementation
From Requirements to Code
Controlling Inheritance
Using Tools to Automate Development
Modeling Implementation and Deployment

3. Reem AlAttas © 3
When do you stop modeling?
When it is easier to construct code than
building more models.

4. Reem AlAttas © 4
Using activity diagrams for operations
Activity diagrams:
 Show the flow of control from one activity to
another.
 Used to investigate the different scenarios in a
use case.
 Show the steps required to collect the set of
rules governing an operation.

5. Reem AlAttas © 5
Class model shows payments made
against a hotel bill

6. Reem AlAttas © 6
A set of rules for payment
authorization
 The hotel need to authorize a payment by
cheque or credit card.

7. Reem AlAttas © 7
Sequence diagrams
Used to illustrate the possible scenarios
for performing a use case.

8. Reem AlAttas © 8
An example of cheque authorization
 One of the hotel’s managers, John, has authorized a
cheque, p101, for payment against a bill, b99.

9. Reem AlAttas © 9
Topic Road Map
Moving towards Implementation
 From Requirements to Code
Controlling Inheritance
Using Tools to Automate Development
Modeling Implementation and Deployment

10. Reem AlAttas © 10
From requirements to implementation
Pre- and post-conditions were recoded in
natural language.
If you want to incorporate them into Java
code as executable statements, you will
need to express them in the Java
language.

11. Reem AlAttas © 11
Assertion
A statement that can be true or false in a
similar way that a Boolean expression will
be either true or false in Java.

12. Reem AlAttas © 12
An ‘extended’ Java syntax for an
assertion handling
 @pre indicates the value of the expression when
the method started its execution.

13. Reem AlAttas © 13
The absence of pre- or post-
conditions
 This does not mean that no pre-condition
applies: it is simply a way of saying that the pre-
condition is true.

14. Reem AlAttas © 14
Not all assertions are easy to express
in a programming language
If it is not possible to express an assertion
formally (in a programming language) it is
good practice to include it informally (in
natural language).
This can be done by including its natural
language version as a comment in the
appropriate pre, post or invariant clause.

15. Reem AlAttas © 15
… Not all assertions are easy to
express in a programming language

16. Reem AlAttas © 16
Invariants and their relationship to pre-
and post-conditions
 The invariant is considered as part of both the
pre- and the post-conditions.
 Before a method can be executed both the invariant and
the pre-condition must hold.
 After the method has completed, the invariant and the
post-condition must hold.

17. Reem AlAttas © 17
The supplier code
 The implementation (code) of a method.

18. Reem AlAttas © 18
The client code
 How to call the method?
 Suppose that acct1 is an object of type
BankAccount.

19. Reem AlAttas © 19
Monitoring assertions

20. Reem AlAttas © 20
Topic Road Map
Moving towards Implementation
From Requirements to Code
 Controlling Inheritance
Using Tools to Automate Development
Modeling Implementation and Deployment

21. Reem AlAttas © 21
Forms of Inheritance
Inheritance for
 Specialization.
 Specification.
 Construction.

22. Reem AlAttas © 22
Inheritance without redefinition of
methods
 Since SavingsAccount
and
SpecialSavingsAccount
are related via
generalization, it means
that an object of class
SpecialSavingsAccount
is-a object of class
SavingsAccount.

23. Reem AlAttas © 23
… Inheritance without redefinition of
methods
The methods that SpecialSavingsAccount
inherits from SavingsAccount have the
same contracts as those in
SavingsAccount.
Inheritance without redefinition guarantees
that this will be the case.

24. Reem AlAttas © 24
Inheritance with redefinition
 Redefined methods
automatically inherit the
pre- and post-conditions
of their parent methods.
 Any invariant clause of
the parent class should
also be inherited by the
child class.
addInterest ()

25. Reem AlAttas © 25
Topic Road Map
Moving towards Implementation
From Requirements to Code
Controlling Inheritance
 Using Tools to Automate Development
Modeling Implementation and Deployment

26. Reem AlAttas © 26
Definitions
 Engineering: generic term often used to describe the
building of an artifact (e.g. software, car, rocket) from
some kind of model.
 Forward engineering: is a synonym for the engineering
process that is often used in CASE tools.
 Code generation: the normal forward engineering
process which automatically generates code.

27. Reem AlAttas © 27
... Definitions
Reverse engineering: is the derivation of
a model from an artifact (which, in the
case of S/W engineering is usually source
code).

28. Reem AlAttas © 28
... Definitions
 Round-trip engineering: going from model to
code and back again (perhaps repeatedly) to
ensure the consistency between model and
code.
 Simultaneous round-trip engineering: edit
code or model and have the other updated
automatically.

29. Reem AlAttas © 29
Topic Road Map
Moving towards Implementation
From Requirements to Code
Controlling Inheritance
Using Tools to Automate Development
 Modeling Implementation and
Deployment

30. Reem AlAttas © 30
Nodes (processing resources)
Run-time, physical objects which have at
least a memory and often processing
capability as well.
Nodes include:
 computing devices.
 human resources.
 mechanical processing resources.

31. Reem AlAttas © 31
Real-world constraint on how a system
may be built and maintained
 The current capabilities of the technology and
probably the budget of the customer.
 Non-functional requirements, such as response
time or robustness, cannot be modeled.
 The programming language and the
environment in which it is coded and
documented.

32. Reem AlAttas © 32
Component
Any distributable part of a system, which
might include executable software, source
code for the software, user manuals or
documentation, or even a specialized
piece of hardware.
If an object can be touched, or stored on a
medium that can be touched, then it can
be a component.

33. Reem AlAttas © 33
Component Symbol

34. Reem AlAttas © 34
A simple component diagram showing
a dependency
class

35. Reem AlAttas © 35
Simple Java program & its
corresponding component diagram

36. Reem AlAttas © 36
Deployment diagram
 Indicates only the components that are active at
run-time.

37. Reem AlAttas © 37
Deployment diagram for home banking

38. Reem AlAttas © 38
Packages
class

39. TMA5 – Q1

40. Thank You!