These slides were presented to the software engineering class held in IAUN. The main context is provided from the "Software Engineering" book authored by Sommerville. Most of the icons used in the slides are provided in the flaticon.com website. Thanks to our professor Habib Seifzadeh. A cooperation with Mohammad Mostajeran.

1. DESIGN AND
IMPLEMENTATION
interleaved

2. OBJECTIVES AND CONTENTS
CONTENTS
1. Object-oriented design using the UML
2. Design patterns
3. Implementation Issues
4. Open source development
OBJECTIVES
⦿ To introduce object-oriented software
design using the UML
⦿ To describe the most important activities in
a general, object-oriented design process
⦿ To describe the different models that may
be used to document an object-oriented
design
⦿ To inform about the idea of design patterns
⦿ To introduce the key issues that have to be
considered when implementing software
2

3. Introduction

4. ⦿ Software design and implementation is the stage at which an
executable software system is developed.
⦿ For some simple systems, it is just software engineering.
⦿ For large systems, it is only one of a set of processes involved in
software engineering.
⦿ Sometimes, there is a separate design stage and this design is
modeled and documented.
⦿ Sometimes the design is in the programmer’s head or roughly
sketched on a whiteboard or sheets of paper
4
concept reality

5. ⦿ At this stage an executable software system is developed.
⦿ Software design and implementation activities are invariably
interleaved.
⌾ In software design you identify software components and their
relationships, based on a customer’s requirements.
⌾ In software implementation you realize the design as a program.
5
DESIGN IMPLEMENTATION
requirements executable

6. BUILD OR BUY
⦿ Buying commercial
off-the-shelf systems (COTS)
is a norm in today’s
environment. It can be
cheaper and faster to use
⦿ The main concern with COTS
is how to use the
configuration features of that
system to deliver the system
requirements.
6

7. OBJECT-ORIENTED
DESIGN USING THE
UML
1

8. Structured design methods propose that software design
should be tackled in a methodical way. Designing a
system involves following the steps of the method and refining
the design of a system at increasingly detailed
levels. In the 1990s, there were a number of competing
methods for object-oriented design. However, the
inventors of the most commonly used methods came together
and invented the UML, which unified the
notations used in the different methods.
8

9. ⦿ Structured object-oriented design processes involve developing a number
of different system models.
⦿ They require a lot of effort for development and maintenance of these
models.
⦿ For large systems developed by different groups design models are an
important communication mechanism.
9

10. 10

11. PROCESS STAGES
11
⦿ There are a variety of different object-oriented design processes that
depend on the organization choice.
Develop
design models

12. SYSTEM CONTEXT
AND INTERACTIONS
1.1

13. 13
⦿ Understanding the relationships helps to
⌾ provide the required system functionalities.
⌾ structure the system to communicate with its
environment.
⦿ Understanding the context helps to establish the
boundaries of the system.
⦿ Context talks about the features.
⦿ Interactions defines the communication between a
system and its environment.

14. 14
⦿ A system context model demonstrates the other
systems in the environment of the system being
developed.
⦿ An interaction model shows how the system interacts
with its environment as it is used.

15. 15
⦿ The context model may be represented using associations.
⦿ You may therefore document the environment of the system
using a simple block diagram, showing the entities in the system
and their associations.
⦿ System context models and interaction models present
complementary views of the relationships between a system
and its environment.

16. 16
⦿ In a block diagram associations simply
show that there are some relationships
between the entities involved in the
association.

17. 17

18. 18
⦿ The use case diagram
does not include too
much details.

19. 19

20. ARCHITECTURAL
DESIGN
1.2

21. 21
⦿ Interactions between the system and
its environment leads to design the
system architecture.
⦿ System architecture consists of
components.
⦿ Then may organize the components
using an architectural pattern.
⦿ However, this is not essential at this
stage.
Layer 1
Layer 2
Layer 3

22. 22
ARCHITECTURAL DIAGRAMS

23. OBJECT CLASS
IDENTIFICATION
1.3

24. 24

25. APPROACHES TO IDENTIFICATION
⦿ Use a grammatical analysis
⌾ Nouns make the objects and
properties
⌾ Verbs make the operations
⦿ Use tangible entities (things)
⌾ Pay attention to roles,
events, locations,
organizations, etc.
⦿ Use a scenario-based analysis
25

26. DESIGN MODELS
1.4

27. Design or system models show the objects and object classes
and relationships between these entities.
These models are the bridge between the system requirements
and the implementation of a system.
They have to be abstract so that unnecessary detail doesn’t
hide the relationships between them and the system
requirements.
However, they also have to include enough detail for
programmers to make implementation decisions.
27

28. Specific design decisions may be made as the system is
implemented, with problems resolved through informal
discussions.
An important step in the design process is to decide on the
design models that you need and the level of detail required in
these models.
The UML supports 13 different types of models but you rarely
use all of these.
28

29. WE NORMALLY DEVELOP TWO KINDS OF DESIGN MODEL
29

30. USEFUL DESIGN MODELS
⦿ Subsystem models
⌾ Show the logical groupings of objects into coherent subsystems.
⌾ Are represented using a form of class diagram.
⌾ Are structural models.
⦿ Sequence models
⌾ Show the sequence of object interactions.
⌾ Are represented using a UML sequence or a collaboration diagram
⌾ Are dynamic models.
⦿ State machine model
⌾ Objects change their state in response to events.
⌾ Are represented using state diagrams.
⌾ Are dynamic models

31. 31

32. 32

33. INTERFACE
SPECIFICATIONS
1.5

34. 34

35. DESIGN PATTERNS
2

36. Design patterns were derived from ideas put forward by
Christopher Alexander (Alexander et al., 1977), who suggested that
there were certain common patterns of building design that were
inherently pleasing and effective.
The pattern is a description of the problem and the essence of its
solution.
The pattern is not a detailed specification.
you can think of it as a description of accumulated wisdom and
experience, a well-tried solution to a common problem.
You can explain your design by describing the patterns that you
have used.
36

37. 37

38. 38

39. IMPLEMENTATION
ISSUES
3

40. REUSE
3.1

41. 41

42. 42
ABSTRACTION
ARCHITECTURAL AND DESIGN PATTERNS
The abstraction level At this level, you don’t reuse
software directly but rather use knowledge of
successful abstractions in the design of your
software. Design patterns and architectural
patterns (covered in Chapter 6) are ways of
representing abstract knowledge for reuse.

43. 43
OBJECT
PROGRAMMING LANGUAGE AND
LIBRARIES
The object level At this level, you directly reuse objects
from a library rather than writing the code yourself. To
implement this type of reuse, you have to find
appropriate libraries and discover if the objects and
methods offer the functionality that you need. For
example, if you need to process email messages in a
Java program, you may use objects and methods from
a JavaMail library.

44. 44
COMPONENT
COMPONENT FRAMEWORKS
The component level Components are collections of objects
and object classes that operate together to provide related
functions and services. You often have to adapt and extend
the component by adding some code of your own. An
example of component-level reuse is where you build your
user interface using a framework. This is a set of general
object classes that implement event handling, display
management, etc. You add connections to the data to be
displayed and write code to define specific display details
such as screen layout and colors.

45. 45
SYSTEM
APPLICATION SYSTEMS (COTS)
The system level At this level, you reuse entire application
systems. This function usually involves some kind of
configuration of these systems. This may be done by adding
and modifying code (if you are reusing a software product line)
or by using the system’s own configuration interface. Most
commercial systems are now built in this way where generic
application systems systems are adapted and reused.
Sometimes this approach may involve integrating several
application systems to create a new system.

46. CONFIGURATION
MANAGEMENT
3.2

47. 47

48. 48
VERSION MANAGEMENT
Version management, where support is provided to keep
track of the different versions of software components.
Version management systems include facilities to
coordinate development by several programmers. They
stop one developer from overwriting code that has been
submitted to the system by someone else.

49. 49
SYSTEM INTEGRATION
System integration, where support is provided to help
developers define what versions of components are used
to create each version of a system. This description is
then used to build a system automatically by compiling
and linking the required components.

50. 50
PROBLEM TRACKING
Problem tracking, where support is provided to allow
users to report bugs and other problems, and to allow all
developers to see who is working on these problems and
when they are fixed.

51. 51
RELEASE MANAGEMENT
Release management, where new versions of a
software system are released to customers.
Release management is concerned with
planning the functionality of new releases and
organizing the software for distribution.

52. HOST-TARGET
DEVELOPMENT
3.3

53. 53

54. 54

55. 55

56. OPEN SOURCE
DEVELOPMENT
4

57. 57
In 1983, Richard Stallman started the GNU project with the
goal of creating a free UNIX-like operating system.[7]
As part
of this work, he wrote the GNU General Public License (GPL).
By the early 1990s, there was almost enough available
software to create a full operating system. However, the
GNU kernel, called Hurd, failed to attract enough
development effort, leaving GNU incomplete.
In 1991, while studying computer science at University of
Helsinki, Linus Torvalds began a project that later became
the Linux kernel. He wrote the program specifically for the
hardware he was using and independent of an operating
system because he wanted to use the functions of his
new PC with an 80386 processor. Development was done
on MINIX using the GNU C Compiler.

58. 58

59. 59
Ways to earn money
from open source
development
1. Freemium and premium
planning
2. Sale support and docs
3. Donations
4. Everything i$ not money!

60. OPEN SOURCE
LICENSING
4.1

61. 61

62. ⦿ https:/
/refactoring.guru
⦿ https:/
/www.jenkins.io
⦿ https:/
/www.bugzilla.org
⦿ https:/
/www.taiga.io
⦿ https:/
/docs.docker.com
⦿ https:/
/docs.gitlab.com/ee/ci
⦿ https:/
/www.wikiwand.com/en/History_of_Linux
⦿ https:/
/www.atlassian.com/git/tutorials/compari
ng-workflows
62
REFERENCES AND SUGGESTED READINGS
⦿ Software engineering book by Sommerville

63. THANKS!
Any questions?
Kourosh Sajjadi
Mohammad Mostajeran
63