sma

1. By: Ms. Bhagyashree Bendale
1

2. Contents:
Software Modeling: Introduction to Software Modeling,
Advantages of modeling, Principles of modeling.
Evolution of Software Modeling and Design Methods:
Object oriented analysis and design methods, Concurrent,
Distributed Design Methods and Real-Time Design
Methods, Model Driven Architecture (MDA), 4+1
Architecture, Introduction to UML, UML building
Blocks, COMET Use Case–Based Software Life Cycle.
2

3. Requirement Study: Requirement Analysis, SRS
design, Requirements Modeling.
Use Case: Actor and Use case identification, Use case
relationship (Include, Extend, Use case
Generalization, Actor Generalization), Use case
template.
3

4.  Modeling is relative. We can think of a model
as reality and can build another model from it
(with additional abstractions).
4
fM1
fR
M1
M1
R R
Requirements
Elicitation
I1
M2
M2
Analysis I2
fM2
….
The development of
Software-Systems is a
Transformation of
Models:
Analysis, Design,
Implementation,Testing

5.  It improves the productivity of the development
team
 It reduces the number of defects in the final code
 It improves the understandability of the system
(which btw, eases the integration of new team
members)
 It increases the decomposition and
modularization of the system
 It facilitates the system’s evolution AND
maintenance
 If facilitates the reuse OF parts OF the system IN
new projects
5

6.  Systems development project
◦ Planned undertaking with fixed beginning and end
◦ Produces desired result or product
 Successful development project:
◦ Provides a detailed plan to follow
◦ Organized, methodical sequence of tasks and
activities
◦ Produces reliable, robust, and efficient system
6

7. 7

8. 8

9.  Define what system needs to do (processing
requirements)
 Define data system needs to store and use
(data requirements)
 Define inputs and outputs
 Define how functions work together to
accomplish tasks
 Data flow diagrams and entity relationship
diagrams show results of structured analysis
9

10. 10

11. 11

12. 12

13. Three major steps:
1. Identify the objects
2. Determine their attributes and services
3. Determine the relationships between objects
13

14.  Views information system as collection of
interacting objects that work together to
accomplish tasks
 OOA
 OOD
 OOP
 Object-oriented analysis (OOA)
◦ Defines types of objects that do work of system
◦ Shows how objects interact with users to complete
tasks
14

15.  Object-oriented design (OOD)
◦ Defines object types needed to communicate with
people and devices in system
◦ Shows how objects interact to complete tasks
◦ Refines each type of object for implementation with
specific language of environment
 Object-oriented programming (OOP)
◦ Writing statements in programming language
15

16.  Understandable
◦ maps the “real-world” objects more directly
◦ manages complexity via abstraction and encapsulation
 Practical
◦ successful in real applications
◦ suitable to many, but not all, domains
 Productive
◦ experience shows increased productivity over life-cycle
◦ encourages reuse of model, design, and code
 Stable
◦ changes minimally perturb objects
16

17.  A real-time system is any information
processing system which has to respond to
externally generated input stimuli within a
finite and specified period.
 Distributed system is a system in which
components are distributed across multiple
locations and computer-network.
17

18. 18

19. 19
Phase Structured Object Oriented
Analysis Structuring
Requirements
• DFDs
• ER Analysis
• Decision Tree
Requirements Engg
• Use Case
Modelling
• Analysis
Modelling
(Static & Dynamic)
Design • DB Design
• GUI Design
• Design System
Architecture
• Design Classes
• GUI Design

20.  Object-oriented development approach
 Offered by IBM / Rational
◦ Booch, Rumbaugh, Jacobson
 Unified Modeling Language (UML) used
primarily for modeling
 UML can be used with any OO methodology
 UP defines 4 life cycle phases
◦ Inception, elaboration, construction, transition
20

21.  Reinforces six best practices
◦ Develop iteratively
◦ Define and manage system requirements
◦ Use component architectures
◦ Create visual models
◦ Verify quality
◦ Control changes
21

22. UP is divided into four phases
• Inception
• Elaboration
• Construction
• Transition
22

23. Each phase has iterations, each having the
purpose of producing a demonstrable piece of
software. The duration of iteration may vary from
two weeks or less up to six months.
Inception Elaboration Construction Transition
Iterations Iterations Iterations
Iterations
Iterations
23

24. The iterations and the phases
24

25.  The life-cycle objectives of the project are
stated, so that the needs of every stakeholder
are considered.
 Scope and boundary conditions, acceptance
criteria and some requirements are
established.
25

26.  An analysis is done to determine the risks,
stability of vision of what the product is to
become, stability of architecture and
expenditure of resources.
 Define the architecture.
 Validate the architecture.
 Baseline the architecture
26

27.  The Construction phase is a manufacturing
process.
 It emphasizes managing resources and
controlling operations to optimize costs,
schedules and quality.
 Develop and test components.
 Manage resources and control process.
 Assess the iteration
27

28.  The transition phase is the phase where the
product is put in the hands of its end users.
 It involves issues of marketing, packaging,
installing, configuring, supporting the user-
community, making corrections, etc.
28

29. 29
 Concurrent Object Modeling and architectural
design mEThod
 COMET is a design method for UML
supporting OO systems
◦ Concurrent
◦ Distributed
◦ Real-Time
 Compatible with USDP (Unified Software
Development Process)

30. 30
 A highly iterative process
 Focuses on the use case concept
◦ Functional requirements are recorded in terms of
actors and their use of the system, collected into
use cases.
◦ A use case is a series of interactions between one
or more actors and the system

31. 31

32. 32
 Requirements Modeling
◦ Use cases are generated, and serve as the
requirements for the system.
◦ Throwaway prototypes can help to clarify the
requirements.
 Analysis Modeling
◦ Static Models
 Class Diagrams show the classes of the problem domain.
◦ Dynamic Models
 Show the problem domain objects participating in use
cases.

33. 33
 Design Modeling
◦ Software architecture is designed
◦ Problem Domain (Analysis Mode) is mapped to
Solution Domain (Design Model)
◦ Subsystems are identified and structured
 Emphasis is on designing distributed subsystems as
configurable components that communicate with each
other via messaging.

34.  Unified Modeling Language
◦ OMG Standard, Object Management Group
◦ Based on work from Booch, Rumbaugh, Jacobson
 UML is a modeling 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
34

35.  Open Standard, Graphical notation for
◦ Specifying, visualizing, constructing, and documenting
software systems
 Language can be used from general initial design
to very specific detailed design across the entire
software development lifecycle
 Increase understanding/communication of
product to customers and developers
 Support for diverse application areas
 Support for UML in many software packages
today (e.g. Rational, plugins for popular IDE’s like
NetBeans, Eclipse)
 Based upon experience and needs of the user
community
35

36.  Inundated with methodologies in early 90’s
◦ Booch, Jacobson, Yourden, Rumbaugh
 Booch, Jacobson merged methods 1994
 Rumbaugh joined 1995
 1997 UML 1.1 from OMG includes input from
others, e.g. Yourden
 UML v2.0 current version
36

37. 37

38. 38

39.  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 textual rules for
depicting views
 Views and models of a single system may overlap
each other
Examples:
 System: Aircraft
 Models: Flight simulator, scale model
 Views: All blueprints, electrical wiring, fuel system
39

40.  UML is a multi-diagrammatic language
◦ Each diagram is a view into a model
 Diagram presented from the aspect of a particular
stakeholder
 Provides a partial representation of the system
 Is semantically consistent with other views
◦ Example views
40

41. 41
Logical view
Physical View
Process View
Development
view
End user
System Engineer
Integrator
Programmers
& software
managers
Scenarios

42. 42

43. 43

44.  Use Cases
◦ Capture requirements
 Analysis Model
◦ Capture process, key classes
 Design Model
◦ Capture details and behaviors of use cases and
domain objects
◦ Add classes that do the work and define the
architecture
44

45.  Use Case Diagrams
 Class Diagrams
 Package Diagrams
 Interaction Diagrams
◦ Sequence
◦ Collaboration
 Activity Diagrams
 State Transition Diagrams
 Deployment Diagrams
45

46.  Used during requirements
elicitation to represent
external behavior
 Actors represent roles, that
is, a type of user of the
system
 Use cases represent a
sequence of interaction for a
type of functionality;
summary of scenarios
 The use case model is the
set of all use cases. It is a
complete description of the
functionality of the system
and its environment
46
Passenger
PurchaseTicket

47.  An actor models an external entity
which communicates with the
system:
◦ User
◦ External system
◦ Physical environment
 An actor has a unique name and
an optional description.
 Examples:
◦ Passenger: A person in the train
◦ GPS satellite: Provides the system with
GPS coordinates
47
Passenger

48. A use case represents a class of
functionality provided by the
system as an event flow.
A use case consists of:
 Unique name
 Participating actors
 Entry conditions
 Flow of events
 Exit conditions
 Special requirements
48
PurchaseTicket

49.  <<extends>> relationships
represent exceptional or
seldom invoked cases.
 The exceptional event flows are
factored out of the main event
flow for clarity.
 Use cases representing
exceptional flows can extend
more than one use case.
 The direction of a <<extends>>
relationship is to the extended
use case
49
Passenger
PurchaseTicket
TimeOut
<<extends>>
NoChange
<<extends>>
OutOfOrder
<<extends>>
Cancel
<<extends>>

50.  <<includes>> relationship
represents behavior that is
factored out of the use
case.
 <<includes>> behavior is
factored out for reuse, not
because it is an exception.
 The direction of a
<<includes>> relationship is
to the using use case
(unlike <<extends>>
relationships).
50
Passenger
Purchase Ticket
PurchaseMultiCard
<<includes>>
CollectMoney
<<includes>>

51.  Determining requirements
◦ New use cases often generate new requirements
as the system is analyzed and the design takes
shape.
 Communicating with clients
◦ Their notational simplicity makes use case
diagrams a good way for developers to
communicate with clients.
 Generating test cases
◦ The collection of scenarios for a use case may
suggest a suite of test cases for those scenarios.
51

52. 52
Number Unique use case number
Name Brief noun-verb phrase
Summary Brief summary of use case major actions
Priority 1-5 (1 = lowest priority, 5 = highest priority)
Preconditions What needs to be true before use case “executes”
Postconditions What will be true after the use case successfully “executes”
Primary Actor(s) Primary actor name(s)
Secondary Actor(s) Secondary actor name(s)
Trigger The action that causes this use case to begin
Main Scenario Step Action
Step # This is the “main success scenario” or “happy path.”
… Description of steps in successful use case “execution”
… This should be in a “system-user-system, etc.” format.
Extensions Step Branching Action
Step # Alternative paths that the use case may take
Open Issues Issue # Issues regarding the use case that need resolution
Use Case Specification Template

53. Number 1
Name Withdraw Money
Summary User withdraws money from one of his/her accounts
Priority 5
Preconditions User has logged into ATM
Postconditions User has withdrawn money and received a receipt
Primary Actor(s) Bank Customer
Secondary Actor(s) Customer Accounts Database
53
Use Case Specification Template Example
Continued
…

54. 54
Trigger User has chosen to withdraw money
Main Scenario Step Action
1 System displays account types
2 User chooses account type
3 System asks for amount to withdraw
4 User enters amount
5 System debits user’s account and dispenses money
6 User removes money
7 System prints and dispenses receipt
8 User removes receipt
9 System displays closing message and dispenses user’s ATM card
11 User removes card
10 System displays welcome message
Extensions Step Branching Action
5a System notifies user that account funds are insufficient
5b System gives current account balance
5c System exits option
Open Issues 1 Should the system ask if the user wants to see the balance?

55.  Use case diagrams represent external
behavior
 Use case diagrams are useful as an index into
the use cases
 Use case descriptions provide meat of model,
not the use case diagrams.
 All use cases need to be described for the
model to be useful.
55

56. 56