for coding and implementation, there is a need of more specific and detailed requirements. The output of this process can directly be used into implementation in programming languages.

1. Software Modelling and
Design

2. SDLC
• Software Development Life Cycle, SDLC for short, is a well-defined,
structured sequence of stages in software engineering to develop the
intended software product.
• There are following six phases in every Software development life
cycle model:
✔Requirement gathering and analysis
✔Design
✔Implementation or coding
✔Testing
✔Deployment
✔Maintenance

3. Introduction to software design
It is phase in SDLC which covert Customer
requirements from application domain to
technical domain.

4. Software Design
• Software design is a process to transform user requirements into
some suitable form, which helps the programmer in software coding
and implementation.
• For assessing user requirements, an SRS (Software Requirement
Specification) document is created whereas for coding and
implementation, there is a need of more specific and detailed
requirements. The output of this process can directly be used into
implementation in programming languages.
• Software design is the first step in SDLC (Software Design Life
Cycle), which moves the concentration from problem domain to
solution domain.
• It tries to specify how to fulfill the requirements mentioned in SRS.

5. Structured Design
• Objective of structured designing was to organize the entire system
in well defined modules.
• Benefit of structured design is, it gives better understanding of how
the problem is being solved.
• Structured design is mostly based on ‘divide and conquer’ strategy
where a problem is broken into several small problems and each small
problem is individually solved until the whole problem is solved.
• The small pieces of problem are solved by means of solution modules.
Structured design emphasis that these modules be well organized in
order to achieve precise solution.
• These modules are arranged in hierarchy. They communicate with
each other.

6. A good structured design always follows some rules for communication
among multiple modules, namely -
- Cohesion - grouping of all functionally related elements.
- Coupling - communication between different modules.
A good structured design has high cohesion and low coupling
arrangements.

7. Structured chart is the primary tool used in structure design.
The structure chart graphically depicts modular structure of software.
The structure chart helps to partition program into small modules,
shows the hierarchy of modules and communication between modules.
A structure chart uses following set of symbols:
1.Rectangles: It is used to represent modules. There is usually one main
module which is placed at top of the chart.
2.Connector: every module is connected to all other modules which it
directly calls by a connector.
3.Data flow arrows: Arrow headed line with small circle at other end
along with name of data on it is used to show flow of data.
Structured Chart

8. In structured Design the DFD’s are converted to structure chart.
A structure chart contains modules which appear in DFD’s as
process.
l Following steps are used for transforming DFD to
structure chart:
Identify the input stream, output stream and processing centre.
- The input stream is the logical process that perform read and edit
input.
- The output stream is the logical process that perform the write
- The processing center is the logical process that performs operations.

9. Notations for DFD

10. Example given is of a payroll system which contains five gigantic
processes : Get Transaction, Get EmpDetails, Calculate Employee Pay,
Generate Accounting Entries, Produce Employee Pay Cheque.

11. Example of Structured Design

12. Object Oriented Design
• Object oriented design works around the entities and their
characteristics instead of functions involved in the software system.
• This design strategies focuses on entities and its characteristics.
The whole concept of software solution revolves around the engaged
entities.
• Design Process
• Software design process can be perceived as series of well-defined
steps. Though it varies according to design approach (function
oriented or object oriented)

13. It may have the following steps involved:
• A solution design is created from requirement or previous used system
and/or system sequence diagram.
• Objects are identified and grouped into classes on behalf of similarity
in attribute characteristics.
• Class hierarchy and relation among them is defined.
• Application framework is defined.

14. In Object oriented programming everything is represented in the
form of object. Objects interacts with each other by passing
messages through methods..
e.g. Consider an online book store as an application in this customer,
e-book database, Administrator, Inventory, GUI all these are classes
which collaborate with each other for different operations.
Important Terms in Object Oriented Concepts :
• Object:
It is entity in the world which is having its own identity, behavior,
state and Responsibility.
One object is distinguished from other object by its attributes
values.
e.g. Table, person, vehicle, book etc.
Table may have attributes legs, color, base, material type.
Person may have attribute name, age, height, weight etc.

15. procedural / structural VS Object
Oriented

16. Difference Between Procedural and
Object Oriented Programming

17. 4 + 1 Development

18. 4+ 1 VIEWS ARCHITECTURE
A design can have a number of views, these view cover different aspects of the
system to be implemented.
The views in UML :
diagarm

19. 1. Use-Case View:
• It shows functionality which delivered by system to external
actors.
• An actor interacts with the system. Actor can be device, human or
another system.
• Use case view is used by customers, designer, developers and
testers.
2. Logical View:
• It shows how functionality is provided to the end user of the S/W
system. It is mainly for designers and developers.
• The logical view looks inside the system. It describes both static
structure and the dynamic collaborations.
• The static structure is described in class and object diagrams. The
dynamic behavior is described in state machine, interaction and
activity diagrams.

20. 3. Implementation View:
• It consists of the main software artifacts.
l It is mainly for developers.
l The artifacts include different types of code modules shown with
their structure dependencies.
l Component diagrams and Package diagrams are used to implement
this view.
4. Process View:
• It deals with the division of the system into processes and
processors.
l This view includes scalability, throughput, and basic time
performance and can touch on some very complex calculations for
advanced systems.
l Activity diagrams of UML are used to form this view.

21. 5.Deployment View
• It shows physical deployment of the system such as computers and
devices (nodes) and how they connect to each other.
• The deployment view is used by developers, integrator and testers is
represented by the deployment diagram.

22. Unified Process

23. � The Unified Software Development Process is an industry standard software
engineering process
◦ It is commonly referred to as the "Unified Process" or UP
◦ It is the generic process for the UML
◦ It is free - described in "The Unified Software Development Process", ISBN:0201571692"
� UP is:
◦ Use case (requirements) driven
◦ Risk driven
◦ Architecture centric
◦ Iterative and incremental
� UP is a generic software engineering process. It has to be customised
(instantiated) for your project
◦ In house standards, document templates, tools, databases, lifecycle modifications, …
� Rational Unified Process (RUP) is an instantiation of UP
◦ RUP is a product marketed and owned by Rational Corporation
◦ RUP also has to be instantiated for your project
23
The Unified Process (UP)

24. � Iterations are the key to the UP
� Each iteration is like a mini-project including:
◦ Planning
◦ Analysis and design
◦ Integration and test
◦ An internal or external release
� We arrive at a final product release through a sequence of
iterations
� Iterations can overlap - this allows parallel development and
flexible working in large teams
◦ Requires careful planning
� Iterations are organised into phases
24
Iterations

25. � Each iteration
may contain all of
the core
workflows but
with a different
emphasis
depending on
where the
iteration is in the
lifecycle
25
Iteration workflows
Requirement
s
Analy
sis
Desi
gn
Implementation Test
UP specifies 5 core
workflows
An iteration
Planning Assessment
Project specific…
other
workflows

26. � This figure is the
key to
understanding
UP!
� For each phase
we will consider:
◦ The focus in
terms of the core
workflows
◦ The goal for the
phase
◦ The milestone at
the end of the
phase
26
Phases and Workflows
Implementation
Requirement
s
Analysi
s
Desig
n
Tes
t
Inception Elaboratio
n
Constructio
n
Transitio
n
I1 I2 In In+1 In+2 Im Im+1
Preliminary
Iterations
amount of work

27. 27
1.Inception
Inception Elaboratio
n
Constructio
n
Transition
Requirements – establish business case and
scope. Capture core requirements
Analysis – establish feasibility
Design – design proof of concept or technical
prototypes
Implementation – build proof of concept or
technical prototype
Test – not generally applicable
Focus
Goals
Establish feasibility of the project - create proof of concept/technical prototypes
Create a business case
Scope the system - capture key requirements
Identify critical risks
R
A
I
D
amount of work
in each core workflow

28. � Life Cycle Objectives - conditions of satisfaction:
◦ System scope has been defined
◦ Key requirements for the system have been captured. These
have been defined and agreed with the stakeholders
◦ An architectural vision exists. This is just a sketch at this
stage
◦ A Risk Assessment
◦ A Business Case
◦ Project feasibility is confirmed
◦ The stakeholders agree on the objectives of the project
28
Inception - milestone

29. 29
2.Elaboration
Inception Elaboratio
n
Constructio
n
Transition
Requirements – refine system scope and
requirements
Analysis – establish what to build
Design – create a stable architectural baseline
Implementation – build the architectural baseline
Test – test the architectural baseline
Focus
Goals
Create an executable architectural baseline
Refine Risk Assessment and define quality attributes (defect rates etc.)
Capture use cases to 80% of the functional requirements
Create a detailed plan for the construction phase
Formulate a bid which includes resources, time, equipment, staff, cost
R A
I
T
D

30. � Lifecycle Architecture - conditions of satisfaction:
◦ A resilient, robust executable architectural baseline has been
created
◦ The Risk Assessment has been updated
◦ A project plan has been created to enable a realistic bid to be
formulated
◦ The business case has been verified against the plan
◦ The stakeholders agree to continue
30
3.Elaboration - milestone

31. 31
4.Construction
Inception Elaboratio
n
Constructio
n
Transition
Requirements – uncover any requirements that
had been missed
Analysis – finish the analysis model
Design – finish the design model
Implementation – build the Initial Operational
Capability
Test – test the Initial Operational Capability
Focus
Goals
Complete use case identification, description and realization
Finish analysis, design, implementation and test
Maintain the integrity of the system architecture
Revise the Risk Assessment
R A
I
T
D

32. � Initial Operational Capability - conditions of
satisfaction:
◦ The product is ready for beta testing in the user
environment
32
Construction - milestone

33. 33
5.Transition
Correct defects
Prepare the user site for the new software and tailor the software to operate at the user site
Modify software if unforeseen problems arise
Create user manuals and other documentation
Provide customer consultancy
Conduct post project review
Inception Elaboratio
n
Constructio
n
Transition
Requirements – not applicable
Analysis – not applicable
Design – modify the design if problems emerge
in beta testing
Implementation – tailor the software for the user
site. Fix bugs uncovered in beta testing
Test – perform beta testing and acceptance
testing at the user site
Focus
Goals
D
I T

34. � Product Release - conditions of satisfaction:
◦ Beta testing, acceptance testing and defect repair are
finished
◦ The product is released into the user community
34
Transition – milestone

35. COMET

36. COMET USE CASE BASED SOFTWARE
LIFE CYCLE
The software modeling and design method which uses the UML notation
is called COMET (Collaborative Object Modeling and Architectural
Design Method).
• COMET is an iterative use case–driven and object-oriented method that
specifically addresses the requirements, analysis, and design modeling
phases of the software development life cycle.
• Use case and actors are used for describing the system in the
requirements modeling phase.
Use case is the sequence of actions between actors and system.
• Analysis modeling describes the use case along with the object that
participates in the interaction.
• Design modeling allows to develop the architecture, describe the
components and interfaces.

37. 1.Requirements Modeling
• In this phase a requirements model is developed to describe the
functional requirements of the system.
• It contains actors and use cases.
• Narrative description of uses cases is given.
• Active participation and inputs from user are necessary in this
phase.
• To clarify the requirements a throwaway prototype can be created.

38. 2.Analysis Modelling
• In this phase static and dynamic models of the system are developed.
• Static model shows structural relationships with the help of class
diagrams.
• Objects are determined with the help of object structuring criteria.
• Dynamic model is generated from the use cases determined in the
requirements model.
• The communication between the actors and use cases is shown on
communication or sequence diagram.
• State dependent objects are shown on state charts.

39. 3. Design Modelling:
• In this phase, software architecture is developed by mapping the
analysis model to an operational environment.
• The analysis model focuses on problem domain whereas design
model focuses on solution domain.
• Subsystems are created by defining subsystem structuring
criteria. The subsystems are further designed.
• Sequential systems use object-oriented concepts such as
information hiding, inheritance, classes.
• For Concurrent systems like real-time, client/server applications
along with concepts of object oriented , the concepts of concurrent
tasking are also taken into consideration.

40. 4.Incremental Software Construction
• In this phase a subset of the system is selected and constructed for each
increment.
• The subset is selected on the basis of use cases and objects that interact
with the usecases.
• Incremental software construction consists of the detailed design,
coding, and unit testing of the classes in the subset.
• The software is gradually constructed and integrated after the whole
system is constructed.

41. 5.Incremental Software Integration
• In this phase, integration testing of each software increment is done.
• The increment test is developed upon the use cases selected for the
increment.
• It is a type of white box testing where the interfaces between the
objects are tested.
• Every software increment is an incremental prototype. After every
increment is tested completely, then the next one is developed and
integrated with the rest of the system using the above phase.
• If at all there are any mistakes in the software increment, then it goes
through all the phases from the beginning.

42. UML Basic Building Blocks

43. � Things
◦ Modelling elements
� Relationships
◦ Tie things together
� Diagrams
◦ Views showing interesting collections of things
◦ Are views of the model
43
UML building blocks

44. � Structural things – nouns of a UML model
◦ Class, interface, collaboration, use case, active class,
component, node
� Behavioural things – verbs of a UML model
◦ Interactions, state machine
� Grouping things
◦ Package
● Models, frameworks, subsystems
� Annotational things
◦ Notes
44
Things
Some Information
about a thing
packag
e

45. 45
Relationships
dependency
association
composition
aggregation
containment
generalization
realization
The source element depends on the target
element and may be affected by changes to it.
dependency
dependency
dependency
dependency
dependency
dependency
relationship UML syntax brief semantics

46. � Structure diagrams model the structure of the system (the static model)
� Behavior diagrams model the dynamic behavior of the system (the
dynamic model)
� Each type of diagram gives a different type of view of the model
46
UML has 13 types of diagram
italics indicates an
abstract category
of diagram types
normal font indicates an actual type of
diagram that you can create

47. � The heading specifies the kind of
diagram, it’s name and any
information (parameters) needed
by elements in the diagram
� The frame may be implied by a
diagram area in the UML tool
47
UML 2 diagram syntax
headin
g
contents
area
frame
implied frame
heading syntax: <kind> <name>
<parameters>
N.B. <kind> and <parameters> are optional

48. Use case Modelling

49. Use case Template