Download Principles and Phases of Object-Oriented Analysis, Design, and Software Development and more Slides Java Programming in PDF only on Docsity!
Object Oriented Analysis and Design and Software Development Process PhasesCalin Curescu
Object Oriented Analysis and Design and
Software Development Process Phases
Calin Curescu
TDDC32 lecture 7, 200628 pages Object Oriented Analysis and Design and Software Development Process PhasesCalin Curescu TDDC32 lecture 7, 20062 of 28
Why object oriented?
- Because of growing complexity!
- How do we deal with it? **1. Divide and conquer
- Iterate and increment
- Reuse and recycle
- Strong cohesion and low coupling**
Object Oriented Analysis and Design and Software Development Process PhasesCalin Curescu TDDC32 lecture 7, 20063 of 28
Principles of OO
- Abstraction
- Identify essential characteristics
- 1,2,
- Hierarchy
- Encapsulation
- Need to know principle
- 4,
- Classification
- Bring similar things together
- 3,1,
- Polymorphism
- Classify related differences
- 3,
- References
- “Object Oriented …”
- By UML guys
- And many others
Object Oriented Analysis and Design and Software Development Process PhasesCalin Curescu TDDC32 lecture 7, 20064 of 28
OO-A/D/P and Processes
- Business modeling
- Capture requirements
- Analysis
- Design
- Implementation
- Testing and validation
- Deployment
- Configuration and change
- Project management
Before and after contract
- Inception
- Elucidate requirements
- Perform a rough OOA + OOD
- Calculate resources and costs
- Elaboration, construction, transition
- Detailed OOA & OOD
- Test planning and testing
- Lots of documents
Requirements
- Functional
- What the system should do!
- Client should be able to withdraw cash
- Students should be registered
- Non-functional
- How it should behave while doing it
- portability
- reliability
- performance
- testability
- modifiability
- security
- cost
- presentation
- reusability
- understandability
- acceptance criteria
- interoperability
Object Oriented Analysis and Design and Software Development Process PhasesCalin Curescu TDDC32 lecture 7, 20067 of 28
Requirements
- Satisfiability
- Criticality
- Mandatory
- Desirable
- Non-critical
- Stability
- User types
- Ones that order
- Ones that use
Object Oriented Analysis and Design and Software Development Process PhasesCalin Curescu TDDC32 lecture 7, 20068 of 28
Requirements Specification
- Correct. There should be no factual errors.
- One interpretation only. We have seen a few examples of ambiguous statements above.
- The SRS should be complete.
- But requirements do change. So the format should allow changes
- All requirements must be verifiable (testable).
- All requirements must be consistent and non-conflicting.
- The requirements specification should be design neutral
- Concentrate on what the system should do not on how it should do it.
Object Oriented Analysis and Design and Software Development Process PhasesCalin Curescu TDDC32 lecture 7, 20069 of 28
What should we do? (1)
- Requirements
- Requirements specification
- Construct use cases
- Is any use case not described in the requirements specification?
- Are there any conflicts between the descriptions and specification?
…Iterative …Incremental
Object Oriented Analysis and Design and Software Development Process PhasesCalin Curescu TDDC32 lecture 7, 200610 of 28
What should we do? (2)
- Object oriented analysis
- Find objects and relations
- Substantive
- Brainstorm
- Checklist
- Delegate responsibilities of activities to objects
- What should they do?
- CRC cards
- Create Class diagrams
- Interaction diagrams
- Sequence diagrams
- Collaboration diagrams
What should we do? (3)
- Object oriented design
- Detail class diagrams
- Detail interaction diagrams
- Detail statecharts and/or activity diagrams
- Create test plans
- Unit tests
- Integration tests
- Implement and Test
- Note all the activities in the last 3 slides are
How to find objects
- Substantives
- From requirements specification
- From use cases
- Brainstorming
- Checklist
- Roles
- Facts
- Situations
- Interactions
• Afterwards: classify, group, eliminate, relate them
- Design patterns are useful here
- Concepts
- Information
- Controllers
- Outer entities
Object Oriented Analysis and Design and Software Development Process PhasesCalin Curescu TDDC32 lecture 7, 200619 of 28
More objects to add
- A result links a student a grade and a moment
- Grade follows even if moved to another group
- If a group member resigns – the other has the grade
Object Oriented Analysis and Design and Software Development Process PhasesCalin Curescu TDDC32 lecture 7, 200620 of 28
Do an assessment
- Do we still need some objects?
- Do we have not necessary ones?
- Do we still have some new relationships?
- Do we have some not necessary relationships?
- Remember
- Association
- Generalisation
- Aggregation
- Composition
Object Oriented Analysis and Design and Software Development Process PhasesCalin Curescu TDDC32 lecture 7, 200621 of 28
Specialisations of person
Object Oriented Analysis and Design and Software Development Process PhasesCalin Curescu TDDC32 lecture 7, 200622 of 28
Define responsibilities for objects
- Good objects do one (or a few) things well
- Otherwise we have to split the object
- Remember divide and conquer
- It can be a more complex task
- That needs several operations
- Needs collaboration with other objects
- Classes can have attributes and operations
- And they represent what?
- Remember
- low coupling among objects
- Strong cohesion within object
Some rules of the thumb
- The expert
- If a class has the knowledge to do something then let it do it
- But not too many things
- Who creates whom? – B creates A if
- B contains A
- B is responsible for storing A
- Uses A (strongly coupled)
- B has the initialisation data for A
- Factory? Anyone?
- Who deals with system functions?
- The objects used until now are descriptive (contain data)
- Should we use “Course” to get the lab registration, set grade, write lists – what if a course disappears?
- Or should we use a controller?
- Remember design patterns?
- E.g. “StudentHandler”
After adding some controller objects
Object Oriented Analysis and Design and Software Development Process PhasesCalin Curescu TDDC32 lecture 7, 200625 of 28
More responsibilities
- Look at he requirements
- Look at the use cases
- “assistant sets the grade for a student at a certain moment”
- Handled by assistant handler
- Who should manipulate the grade?
- Should the assistant handler create it and send to student?
- Should the student create it?
Object Oriented Analysis and Design and Software Development Process PhasesCalin Curescu TDDC32 lecture 7, 200626 of 28
Cohesion and coupling again
- For each communication with a new class the coupling increases - Create, return, have as argument, call method…
- Internal data should be private
- Use interfaces to provide only a part of the object
- Or use private and protected modifiers
- A class should not have several strong relationships with two other classes - Increases coupling
Object Oriented Analysis and Design and Software Development Process PhasesCalin Curescu TDDC32 lecture 7, 200627 of 28
Coupling example
