This document discusses object-oriented system design and modeling. It introduces key concepts like object-oriented principles, the software development lifecycle, and UML modeling. It explains that object-oriented concepts are widely used in software solution design across domains. Skilled professionals with a strong foundation in object-oriented design are needed to fulfill increasing requirements. The document then covers stages of software development like analysis, design, and implementation. It also discusses phases of object-oriented development like analysis, design, and self-contained objects and classes.

1. Object Oriented System Design
MODULE-1
Amity University, Noida

2. Course Objective
• The purpose of this module is to acquaint students with key aspects
of object-oriented principles and systems modeling.
• It also aims to give students skills in the use of appropriate tools
and familiarity with techniques applied at different stages of the
software development lifecycle. Object oriented concepts have
been the backbone of software solution design across platform
such as embedded, internet and business solution. Over the years
the market is growing stronger and bigger size.
• Meanwhile, the need for reliable and scalable software solution
design is ever-increasing. Hence, the skilled professionals with good
foundation of object oriented concepts are needed to fulfill the
ever increasing requirements.

3. Module - 1
• CLO1-Understanding the concept of OOSA &
OOSD with UML.

16. Introduction to OOSD
• Technical approach
Analyzing + Designing ->
(Application,
System, business)
applying
Object-oriented
programming,
using
visual modeling
for stake
holderes and product
quality

17. • Designing software for large applications is a very complextask.
It could arguably be said that there is no limit to how complex software
design could get. The reason for this is that we generally design software
to model some real-world phenomenon.

18. • This course forms a strong foundation
in:-
• Understanding and design of modern
computing systems.
• This course explores techniques that go into
designing a modern microprocessor.
• Concepts of Object Oriented design

19. • Stages of normal software development
• Analysis,
• Design, and
• Implementation

20. • Phases in Object-Oriented Software
Development
• object-oriented analysis.

21. • object-oriented design
• Self contained Objects+ Classes

22. What is OOSD?
• The Object-Oriented Software Development Method (OOSD) includes
object-oriented requirements analysis, as well as object-oriented design.
• OOSD is a practical method of developing a software system which
focuses on the objects of a problem throughout development.
• OOSD's focus on objects early in the development, with attention to
generating a useful model, creates a picture of the system that is
modifiable, reusable, reliable, and understandable.

23. Object Oriented Design

24. • What is UML
• UML, short for Unified Modeling Language, is a
standardized modeling language consisting of an
integrated set of diagrams.
• Developed to help system and software
developers for specifying, visualizing,
constructing, and documenting the artifacts of
software systems, as well as for business
modeling and other non-software systems.

25. Origin
• UML is a notation that resulted from the unification of OMT from
• Object Modeling Technique OMT [James Rumbaugh 1991] - was
best for analysis and data-intensive information systems.
• Booch [Grady Booch 1994] - was excellent for design and
implementation. Grady Booch had worked extensively with
the Ada language, and had been a major player in the development
of Object Oriented techniques for the language. Although the
Booch method was strong, the notation was less well received (lots
of cloud shapes dominated his models - not very tidy)
• OOSE (Object-Oriented Software Engineering [Ivar Jacobson 1992])
- featured a model known as Use Cases. Use Cases are a powerful
technique for understanding the behavior of an entire system (an
area where OO has traditionally been weak)

27. History

28. • A software development will have many
stakeholders playing a part.
• For Example:
• Analysts
• Designers
• Coders
• Testers
• QA
• The Customer
• Technical Authors

29. • All of these people are interested in different aspects
of the system, and each of them require a different
level of detail.
• For example, a coder needs to understand the design
of the system and be able to convert the design to a
low level code.
• By contrast, a technical writer is interested in the
behavior of the system as a whole, and needs to
understand how the product functions.
• The UML attempts to provide a language so expressive
that all stakeholders can benefit from at least one UML
diagram.

30. UML 2 Diagram Structure below:
• Structure diagrams show the static structure of
the system and its parts on different abstraction
and implementation levels and how they are
related to each other.
• The elements in a structure diagram represent
the meaningful concepts of a system, and may
include abstract, real world and implementation
concepts, there are seven types of structure
diagram as follows:

31. UML Diagrams

32. • Class Diagram
• Component Diagram
• Deployment Diagram
• Object Diagram
• Package Diagram
• Composite Structure Diagram
• Profile Diagram

33. • Behavior diagrams show the dynamic behavior of the objects in a
system, which can be described as a series of changes to the system
over time, there are seven types of behavior diagrams as follows:
• Use Case Diagram
• Activity Diagram
• State Machine Diagram
• Sequence Diagram
• Communication Diagram
• Interaction Overview Diagram
• Timing Diagram

35. Use case Modeling :
• Use case modeling is a useful tool for requirements elicitation. It provides a graphical
representation of the software system's requirements.
• The key elements in a use case model are actors (external entities), and the use
cases themselves. In outline, a use case is a unit of functionality (a requirement), or a service,
in the system. A use case is not a process, or program, or function.
• Because use case models are simple both in concept and appearance, it is relatively easy to
discuss the correctness of a use case model with a non-technical person (such as a customer).
• Use case modeling effectively became a practicable analysis technique with the publication of
Ivar Jacobson's (1991) book “Object-oriented software engineering: a use case driven
approach”. Jacobson has continued to promote this approach to system analysis to the
present day, and it has now been formalized as part of the UML. However, use case modeling
is not very different in its purpose and strategy from earlier techniques, such as structured
viewpoint analysis

36. Unified Process

37. Components Relation in 3 components

38. Unified Process
• Unified Process is based on the enlargement
and refinement of a system through multiple
iterations, with cyclic feedback and
adaptation. The system is developed
incrementally over time, iteration by iteration,
and thus this approach is also known as
iterative and incremental software
development.

39. Unified Process: Phases and Major
Milestones
• Inception
• The primary goal of the Inception phase is to establish the case for
the viability of the proposed system.
• The tasks that a project team performs during Inception include the
following:
• Defining the scope of the system (that is, what's in and what's out)
• Outlining a candidate architecture, which is made up of initial
versions of six different models
• Identifying critical risks and determining when and how the project
will address them
• Starting to make the business case that the project is worth doing,
based on initial estimates of cost, effort, schedule, and product
quality

40. Elaboration
• The primary goal of the Elaboration phase is to establish the ability to build the
new system given the financial constraints, schedule constraints, and other kinds
of constraints that the development project faces.
• The tasks that a project team performs during Elaboration include the following:
• Capturing a healthy majority of the remaining functional requirements
• Expanding the candidate architecture into a full architectural baseline, which is an
internal release of the system focused on describing the architecture
• Addressing significant risks on an ongoing basis
• Finalizing the business case for the project and preparing a project plan that
contains sufficient detail to guide the next phase of the project (Construction)

41. • Construction
• The primary goal of the Construction phase is to build a
system capable of operating successfully in beta customer
environments.
• During Construction, the project team performs tasks that
involve building the system iteratively and incrementally
(see "Iterations and Increments" later in this chapter),
making sure that the viability of the system is always
evident in executable form.
• The major milestone associated with the Construction
phase is called Initial Operational Capability. The project
has reached this milestone if a set of beta customers has a
more or less fully operational system in their hands.

42. • Transition
• The primary goal of the Transition phase is to
roll out the fully functional system to
customers.
• During Transition, the project team focuses on
correcting defects and modifying the system
to correct previously unidentified problems.
• The major milestone associated with the
Transition phase is called Product Release

44. • Quiz 1

45. Case study – the NextGen POS system,

46. Open ended question
• Identify : Primary and secondary actors in
NextGen POS
• Design Use Case for Process Sale

47. Symbols

48. • There can be 5 relationship types in a use case
diagram.
• Association between actor and use case
• Generalization of an actor
• Extend between two use cases
• Include between two use cases
• Generalization of a use case

49. • Association Between Actor and Use Case
• This one is straightforward and present in
every use case diagram. Few things to note.
• An actor must be associated with at least one
use case.
• An actor can be associated with multiple use
cases.
• Multiple actors can be associated with a single
use case.

50. Association Between Actor and Use
Case

51. • Generalization of an Actor
• Generalization of an actor means that one
actor can inherit the role of the other actor.
The descendant inherits all the use cases of
the ancestor. The descendant has one or more
use cases that are specific to that role. Let’s
expand the previous use case diagram to show
the generalization of an

53. Extending
• The extending use case is dependent on the extended
(base) use case. In the below diagram the “Calculate
Bonus” use case doesn’t make much sense without the
“Deposit Funds” use case.
• The extending use case is usually optional and can be
triggered conditionally. In the diagram, you can see
that the extending use case is triggered only for
deposits over 10,000 or when the age is over 55.
• The extended (base) use case must be meaningful on
its own. This means it should be independent and must
not rely on the behavior of the extending use case.

55. • Include Relationship Between Two Use Cases
• Include relationship show that the behavior of the
included use case is part of the including (base) use
case. The main reason for this is to reuse common
actions across multiple use cases. In some situations,
this is done to simplify complex behaviors. Few things
to consider when using the <<include>> relationship.
• The base use case is incomplete without the included
use case.
• The included use case is mandatory and not optional.

56. • Generalization of a Use Case
• This is similar to the generalization of an actor. The
behavior of the ancestor is inherited by the
descendant. This is used when there is common
behavior between two use cases and also specialized
behavior specific to each use case.
• For example, in the previous banking example, there
might be a use case called “Pay Bills”. This can be
generalized to “Pay by Credit Card”, “Pay by Bank
Balance” etc.

57. • Quiz 2

58. References
• Barclay, K., & Savage, J. (2003). Object-
oriented Design with UML and Java. Elsevier.
• Booch, G. (1991). object oriented design; with
applications (No. 04; QA76. 64, B6.).