Software Development - L04

Download as pdf or txt
Download as pdf or txt
You are on page 1of 52

Software Development and Professional Practice

Software Development and Professional Practice


L04: Software Specification Models

Dr. Nora Shoaip


Damanhour University
Faculty of Computers & Information Sciences
Department of Information Systems

2023

1
System Modeling

2
What is UML?

• UML stands for Unified Modeling Language is a


standard language (notation) for specification,
construction, visualization, and documentation of
the artifacts of a software-intensive system
• Notation is a collection of graphical symbols for
expressing model of the system

3
UML Advantages

• Graphical notation is much better than words

• Provides a standard communication language

• Provides multiple diagrams for capturing different architectural views (13


diagrams)

• Promotes component reusability

• Provide structure for problem solving

• Reduce time-to-market for business problem solutions

• Decrease development costs

• Manage the risk of mistakes

4
System Perspectives

5
System Perspectives

6
System Perspectives

7
System Perspectives

8
System Perspectives

9
UML-2 Diagrams
• Use case diagrams represent the functions of a system from
the user’s point of view
• Class diagrams represent the static structure in terms of
classes and relationships
• Object diagrams represent objects and their relationships, and
correspond to simplified collaboration diagrams that do not
represent message broadcasts
• Sequence diagrams are temporal representation of objects
and their interactions
• Collaboration diagrams are spatial representation of objects,
links, and interactions

10
UML Diagrams
• State chart diagrams represent the behavior of a class in
terms of states
• Activity diagrams are to represent the parallel behavior of
an operation as a set of actions
• Component diagrams represent the logical components of
an application
• Deployment diagrams represent the deployment of
components on particular pieces of hardware

11
System Perspectives

12
Context Models

The context of the MentCare system


13
The context of an ATM system

14
Interaction models

15
USE CASE Diagram
• A use case diagram establishes the capability of the system as a
whole from the user’s point of view

• Components of use case diagram:


– Actor
– Use case
– System boundary
– Use cases’ relationships
– Actors’ relationships

16
USE CASE Diagrams – Use Case

• Each use case is a sequence of related actions


performed by an actor and the system in a dialogue
• A use case typically represents a major piece of
functionality that is complete from beginning to end
• Use case is represented by an horizontal ellipsis in
UML, with its name either inside the oval or
underneath it

Open new account

Cash Withdrawal

17
USE CASE Diagrams – Use Case
• Determining use cases:
– What functions will the actor want from the system?
– Does the system store information?
– What actors will create, read, update, or delete that
information?
– Does the system need to notify an actor about changes in
its internal state?
• Associations between actors and use cases are indicated in use
case diagrams by solid lines. An association exists whenever an
actor is involved with an interaction described by a use case.
• System boundary boxes (optional), represented by a rectangle
around the use cases to indicates the scope of your system.
Anything within the box represents functionality that is in scope
and anything outside the box is not.
18
USE CASE Diagrams – Example
System (subject) name

Use Cases
Use case name

Actor name

Association
Actors Actors

System boundary
Association

19
USE CASE Diagram

20
USE CASE Diagrams – Use Case Relationships

• Relationships in use case diagrams divided into two


categories
– Actor relationships: relationships between actors
• if you wish to portray that actors interact among each other
• Generally they do not represent any direct requirements on the
system to be produced, but they clarify the overall situation and the
context of the use case
• Association, generalization/specialization, aggregations or
compositions … etc. can be used
– Use case relationships: Relationships between use cases
• <<extend>>
• <<include>>
• << inheritance>>
21
USE CASE Diagrams – Use Case Relationships
<<extend>>
– is a generalization relationship where an extending use case
continues the behavior of a base use case.
– The extending use case accomplishes this by conceptually
inserting additional action sequences into the base use-case
sequence. This allows an extending use case to continue the
activity sequence of a base use case when the appropriate
extension point is reached in the base use case and the
extension condition is fulfilled. When the extending use case
activity sequence is completed, the base use case continues.
The important point here is that the extending use case
behavior is not always added to the base use case but there
should be a condition that fulfils for this inclusion.

22
USE CASE Diagrams – Use Case Relationships

<<include>>
– It is a generalization relationship denoting the inclusion of all
the behavior described by another use case in the base use
case.
– It can also be considered as an invocation of a use case by
another one. You use include dependencies whenever one
use case needs the behavior of another.
<<Inheritance>>
– Use cases can be inherited from other use cases, offering a
third opportunity to indicate potential reuse. The inheriting
use case would completely replace one or more of the
courses of action of the inherited use case whenever
needed.
23
USE CASE Diagrams – Use Case Relationships

<<extend>> relationship

Inheritance relationship

<<include>> relationship

24
USE CASE Diagrams – Example

25
USE CASE Diagrams – Example

26
USE CASE Description

• Use case diagrams doesn’t provides the details of the


sequence of activities associated with each use case.
• Hence, a narrative description of the sequence of steps is
needed
• It is written in natural language, there is no standard to write
but content-related structuring is recommended
• Each step should clearly show who is carrying out the step
• Steps should show the intent of the actor not the mechanics
of what the actor does

27
USE CASE Description

28
USE CASE Description: include

29
USE CASE Description: include

30
USE CASE Description: Inheritance

31
USE CASE Description: Inheritance

32
USE CASE Description: Inheritance

33
USE CASE Description: extend

34
USE CASE Description: extend

35
USE CASE Description: extend

36
Sequence diagram

37
Sequence diagram

38
Sequence diagram

39
Sequence diagram

40
Sequence diagram

41
Sequence diagram

42
Sequence diagram

43
Sequence diagram

44
Sequence diagram

45
Sequence diagram

46
Sequence diagram

47
Sequence diagram

48
49
Sequence diagram

50
Sequence diagram

51
References

Textbooks
Cha, S., Taylor, R. N., & Kang, K. (Eds.).
(2019). Handbook of software engineering.
Springer International Publishing.‫‏‬
Hodges, J. L. Software Engineering from
Scratch.‫‏‬
Loubser, N. (2021). Software Engineering for
Absolute Beginners. Apress.

52

You might also like