0% found this document useful (0 votes)
48 views

Chapter 4 Introduction To UML and UML Diagrams Class-Based Requirements Design

The document discusses Module 3 of an Object Oriented Software Engineering course. Module 3 covers developing requirements and class-based requirements design modeling with classes over 10 hours. It introduces developing requirements through domain analysis and various types of requirements. Techniques for gathering requirements and managing changing requirements are covered. The introduction to the Unified Modeling Language (UML) and essentials of UML class diagrams such as associations, multiplicity, and generalization are also presented.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
48 views

Chapter 4 Introduction To UML and UML Diagrams Class-Based Requirements Design

The document discusses Module 3 of an Object Oriented Software Engineering course. Module 3 covers developing requirements and class-based requirements design modeling with classes over 10 hours. It introduces developing requirements through domain analysis and various types of requirements. Techniques for gathering requirements and managing changing requirements are covered. The introduction to the Unified Modeling Language (UML) and essentials of UML class diagrams such as associations, multiplicity, and generalization are also presented.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 63

OBJECT ORIENTED SOFTWARE ENGINEERING

COURSE CODE :MCA 2005

Module 3 Developing Requirements And Class-based


Requirements Design Modeling With Classes ( 10 Hours)

1
Module 3_ Part 2 Introduction to UML
and Class-based Requirements Design Modeling With Classes ( 10 Hours)
 3.1 Developing requirements: Domain analysis
 3.2 Types of requirements
 3.3 Requirements gathering
 3.4 object-based requirements analysis
 3.5 Use cases: describing how the user will use the system
 3.6 techniques for gathering requirements
 3.7 Managing changing requirements,
 3.8 class-based requirements design Modeling with
classes:
 Introduction to UML
 3.9 Essentials of UML class diagrams
 3.10 Associations and multiplicity
 3.11 Generalization
 3.12 More advanced features of class
diagrams 2
2
2
SYLLABUS
MODULE 1 AND MODULE 2
NO OF HOURS : 11 HOURS

3
SYLLABUS MODULE 3
HOURS: 10 SESSIONS

4
SYLLABUS MODULE 4
HOURS: 12 SESSIONS

5
SYLLABUS MODULE 5
HOURS: 10 SESSIONS

6
Text Books:

7
Reference Books:

8
Module 3_ Part 2 Introduction to UML
and Class-based Requirements Design Modeling With Classes ( 10 Hours)
 3.1 Developing requirements: Domain analysis
 3.2 Types of requirements
 3.3 Requirements gathering
 3.4 object-based requirements analysis
 3.5 Use cases: describing how the user will use the system
 3.6 techniques for gathering requirements
 3.7 Managing changing requirements,
 3.8 class-based requirements design Modeling with
classes:
 Introduction to UML
 3.9 Essentials of UML class diagrams
 3.10 Associations and multiplicity
 3.11 Generalization
 3.12 More advanced features of class
diagrams 9
9
9
MODULE 3 _PART 2 : TOPICS

 INTRODUCTION TO UML & MODELLING CONCEPTS

 TYPES OF UML DIAGRAMS WITH EXAMPLES

 USER-CENTERED DESIGN

 CHARACTERISTICS OF UML

 DEVELOPING USE-CASE MODELS

 USE-CASE DIAGRAMS

 USE-CASE DESCRIPTIONS

 BASICS OF USER INTERFACE DESIGN

 USABILITY PRINCIPLES & USER INTERFACES


10
INTRODUCTION TO UML

11
INTRODUCTION TO UML – Brief History
o At the end of the 1980’s and the beginning of 1990’s, the first
Object-Oriented Development processes appeared.
• - Booch, Jacobson, Yourden, Rumbaugh

o In 1994, ‘Rumbaugh’ & ‘Booch’ decided to merge two important


methodologists & their approaches.
• They worked together at the Rational Software Corporation.

o In 1995, another methodologist, ‘Jacobson’, joined ‘Rumbaugh’


to the team his work focused on use cases.

o In 1997, the Object Management Group (OMG) started the


process of UML standardization.
o UML V2.0 is current version. 12
WHAT IS UML?
 UML – Unified Modelling Language
 The Unified Modelling Language is a standard graphical
language for modelling object oriented software.
 UML is a standard language for specifying, visualizing,
constructing, and documenting the artifacts of software
systems.
 UML is different from the other common programming
languages such as C++, Java, COBOL, etc.
 UML is a pictorial language used to make software blueprints.

UML can be described as a general purpose visual modeling


language to visualize, specify, construct, and document
software system.
What's UML and Why Do You Need It?
https://www.youtube.com/watch?v=8CBnAmYnwk0 13
14
WHAT IS UML? (Contd.)
 UML is a modelling language to express and design
documents, software:
- Particularly useful for OO Design
- Not a process, but some have been proposed using UML
- Independent of implementation language.

WHY USE UML?


 Language can be used from general initial design to very
specific detailed design across the entire software development
lifecycle.
 Open Standard, Graphical notation for specifying, visualizing,
constructing, and documenting the artifacts of software
systems.
 Support for diverse application areas.
15
 Based open experience and needs of the user community.
Basic Building Blocks of UML

16

UML for Designers_ Keynote Speech by Dr.M.K.Jayanthi Kannan


17
MODELLING CONCEPTS

18
19
Systems, Models & Views
 A Model is an abstraction describing a subset of a system.
 A View depicts selected aspects of a model.
 A Notation is a set of graphical or textural rules for depicting
views.
 Views & Models of a single system overlap each other.

 Example:
 System: Aircraft

 Models: Flight Simulator, Scale Model

 Views: All blueprints, Electrical wiring, Fuel system.

20
Systems, Models & Views
 Example - System: Aircraft

21
Models, Views & Diagrams
 The below shows different model, view & diagrams:

22
BASIC MODELLING STEPS
 Use Case
 Capture Requirements

 Domain Model
 Capture Process, Key Classes

 Design Model
 Capture details & behaviour of use cases & domain
objects.
 Add classes that do the work & define the architecture.

23
24
UML MODELLING CONCEPTS
 The building blocks of UML can be defined as:
(1) Things
(2) Relationships
(3) UML Diagrams

(1) Things: are the most important building blocks of UML.


Things can be:

(i) Structural Things


(ii) Behavioral Things
(iii) Grouping Things
(iv) Annotational Things

25
UML MODELLING CONCEPTS (Contd.)
(i) Structural Things - define the static part of the model. They
represent the physical and conceptual elements.
(a) Class − Class represents a set of objects having similar responsibilities.
(b) Interface − Interface defines a set of operations, which specify the
responsibility of a class.
(c) Collaboration −Collaboration defines an interaction between elements.
(d) Use case −Use case represents a set of actions performed by a system for
a specific goal.
(e) Component −Component describes the physical part of a system.
(f) Node − A node can be defined as a physical element that exists at run
time.

Class Interface Collaboration Use case

Node
Component
26
UML MODELLING CONCEPTS (Contd.)
(ii) Behavioral Things: consists of the dynamic parts of UML
models. Following are the behavioral things:
(a) Interaction − Interaction is defined as a behavior that consists of a group of
messages exchanged among elements to accomplish a specific task.

(b) State machine − State machine is useful when the state of an object in its
life cycle is important. It defines the sequence of states an object goes through
in response to events. Events are external factors responsible for state
change.

(iii) Grouping Things: can be defined as a mechanism to group


elements of a UML model together. There is only one grouping thing
available:
(a) Package − Package is the only one grouping thing available for gathering
structural and behavioral things.
27
UML MODELLING CONCEPTS (Contd.)
(iv) Annotational Things: can be defined as a mechanism to
capture remarks, descriptions, and comments of UML model
elements.
(a) Note - It is the only one Annotational thing available. A note is used
to render comments, constraints, etc. of an UML element.

(2) Relationships: is another most important building block of UML.


It shows how the elements are associated with each other and this
association describes the functionality of an application. There are
four kinds of relationships available:
(i) Dependency
(ii) Association
(iii) Generalization
(iv) Realization 28
UML MODELLING CONCEPTS (Contd.)
(i) Dependency : Dependency is a relationship between two things in
which change in one element also affects the other.

(ii) Association: Association is basically a set of links that connects the


elements of a UML model. It also describes how many objects are taking part
in that relationship.

(iii) Generalization: Generalization can be defined as a relationship


which connects a specialized element with a generalized element. It basically
describes the inheritance relationship in the world of objects.

(iv) Realization: Realization can be defined as a relationship in which two


elements are connected. One element describes some responsibility, which is
not implemented and the other one implements them. This relationship
exists in case of interfaces.
29
30
UML MODELLING CONCEPTS (Contd.)
(3) UML Diagrams
 UML diagrams are the ultimate output of the entire
discussion. All the elements, relationships are used to make a
complete UML diagram and the diagram represents a system.
 The visual effect of the UML diagram is the most important
part of the entire process. All the other elements are used to
make it complete.
 UML includes the following :
 Class diagram
 Object diagram
 Use case diagram
 Sequence diagram
 Collaboration diagram
 Activity diagram
 Statechart diagram 31
 Deployment diagram
 Component diagram
32

UML for Designers_ Keynote Speech by


33
TYPES OF UML DIAGRAMS
WITH EXAMPLES

https://www.youtube.com/watch?v=Yt8XkYIdhVU

34
UML DIAGRAMS
(a) Class diagrams:
 describe classes and their relationships

(b) Interaction diagrams:


 show the behaviour of systems in terms of how objects
interact with each other
 interactive behavior is represented in UML by two diagrams

known as Sequence diagram and Collaboration


diagram.

(c) State diagrams and activity diagrams:


 show how systems behave internally

(d) Component and deployment diagrams: 35

 show how the various components of systems are arranged


logically and physically
36
37
UML DIAGRAMS (Contd.)
(a) Class diagrams: Example of an Customer Order
Management System

38
UML DIAGRAMS (Contd.)
(b) Interaction diagrams: Sequence Diagram -
Example of an Customer Order Management System

39
UML DIAGRAMS (Contd.)
(b) Interaction diagrams: Communication Diagram -
Example of an Customer Order Management System

40
UML DIAGRAMS (Contd.)
(c) State diagrams: Example of an Customer Order
Management System

41
UML DIAGRAMS (Contd.)
(c) Activity diagrams: Example of an Customer Order
Management System

42
UML DIAGRAMS (Contd.)
(d) Component diagrams: Example of an Customer
Order Management System

43
UML DIAGRAMS (Contd.)
(d) Deployment diagrams: Example of an Customer
Order Management System

44
USER-CENTERED DESIGN

45
USER-CENTERED DESIGN (UCD)
 User-centered design is an iterative process that focuses on an
understanding of the users and their context in all stages of
design and development.
 Each iteration of the UCD approach involves four distinct
phases:
(a) Understand the context
(b) Identify & specify user requirements
(c) Design phase
(d) Evaluation phase

46
CHARACTERISTICS OF UML

47
UML CHARACTERISTICS
o The Characteristics of UML is:
 It has detailed semantics
 It has extension mechanisms
 It has an associated textual language
 Object Constraint Language (OCL)

The objective of UML is:


 To assist in software development

It is not a methodology

48
DEVELOPING USE-CASE MODELS
OF SYSTEMS

49
Use-Cases: Describing how the user will use the system

 A use-case is a typical sequence of actions that a user


performs in order to complete a given task.

 The objective of use-case analysis is to model the system from


the point of view of:
 how users interact with this system.

 when trying to achieve their objectives.

It is one of the key activities in requirements analysis

o A use-case model consists of:


 a set of use-cases.

 an optional description or diagram indicating how they

are related.
50
Use-Cases (Contd.)
 A use-case should:
 Cover the full sequence of steps from the beginning of a
task until the end.
 Describe the user’s interaction with the system ...
 Not the computations the system performs.

 Be written so as to be as independent as possible from any


particular user interface design.
 Only include actions in which the actor interacts with the
computer.
 Not actions a user does manually

51
SCENARIOS

 A scenario is an instance of a use case


 A specific occurrence of the use case
 a specific actor ...
 at a specific time ...

 with specific data.

52
Use-Cases (Contd.)

How to describe a single use case:

A. Name: Give a short, descriptive name to the use case.


B. Actors: List the actors who can perform this use case.
C. Goals: Explain what the actor or actors are trying to achieve.
D. Preconditions: State of the system before the use case.
E. Summary: Give a short informal description.
F. Related use cases.
G. Steps: Describe each step using a 2-column format.
H. Postconditions: State of the system in following completion.

A and G are the most important.


53
USE-CASE DIAGRAMS
&
USE-CASE DESCRIPTIONS

54
Use-Cases Representation & Symbols

55
USE-CASE DIAGRAMS (Example-1)
 Example 1: SCHOOL LOGIN SYSTEM

56
USE-CASE DIAGRAMS (Example-2)
 Example 2: STUDENT ADMISSION PROCESS

Register in Course
Add Course Offering

Registrar Actor Add Course

Enter Grade
for Course
Student

Find information about course

57
Professor Actor
DESCRIPTION OF A USE-CASE (Contd.)
Use case: Open file by browsing

Related use cases:


Specialization of: Open file
Includes: Browse for file

Steps:
Actor actions System responses
1. Choose ‘Open…’ command 2. File open dialog appears
3. Browse for file
4. Confirm selection 5. Dialog disappears

58
59
BASICS OF USER INTERFACE DESIGN
USABILITY PRINCIPLES & USER
INTERFACES

60
BASICS OF USER-INTERFACE DESIGN,
USABILITY PRINCIPLES, USER INTERFACES
 Everything depends on fully knowing your users, including
understanding their goals, skills, preferences, and their
tendencies.
 This is important as once you know your user its make it easier
to choose the right interface elements as listed below:
 First keep the interface simple.

 Be sure to create consistency and use the common UI


elements that are expected.
 Choose your page layout carefully.

 Always display the defaults.

 Visibility of system status.

 Match between system and the real world.

 Consistency and standards .


61
 Error prevention.

 Flexibility and efficiency of use .


Module 3 _Part 2 : Summary
So far in this Unit 5 _Part 1, we discussed the following concepts..
 INTRODUCTION TO UML & MODELLING CONCEPTS

 TYPES OF UML DIAGRAMS WITH EXAMPLES

 USER-CENTERED DESIGN

 CHARACTERISTICS OF UML

 DEVELOPING USE-CASE MODELS

 USE-CASE DIAGRAMS

 USE-CASE DESCRIPTIONS

 BASICS OF USER INTERFACE DESIGN

 USABILITY PRINCIPLES & USER INTERFACES 62


63

You might also like