UNIT 1 UNIFIED PROCESS AND USE CASE DIAGRAMS 0/0
Introduction to OOAD with OO Basics – Unified Process – UML diagrams – Use Case –Case study – the Next Gen POS system, Inception -Use case Modelling – Relating Use cases – include, extend and generalization – When to use Use-cases
UNIT II STATIC UML DIAGRAMS 0/1
Class Diagram–– Elaboration – Domain Model – Finding conceptual classes and description classes – Associations – Attributes – Domain model refinement – Finding conceptual class Hierarchies – Aggregation and Composition – Relationship between sequence diagrams and use cases – When to use Class Diagrams
UNIT III DYNAMIC AND IMPLEMENTATION UML DIAGRAMS 0/1
Dynamic Diagrams – UML interaction diagrams – System sequence diagram – Collaboration diagram – When to use Communication Diagrams – State machine diagram and Modelling –When to use State Diagrams – Activity diagram – When to use activity diagrams Implementation Diagrams – UML package diagram – When to use package diagrams – Component and Deployment Diagrams – When to use Component and Deployment diagrams
UNIT IV DESIGN PATTERNS 0/1
GRASP: Designing objects with responsibilities – Creator – Information expert – Low Coupling – High Cohesion – Controller Design Patterns – creational – factory method – structural – Bridge – Adapter – behavioural – Strategy – observer –Applying GoF design patterns – Mapping design to code
UNIT V TESTING 0/1
Object Oriented Methodologies – Software Quality Assurance – Impact of object orientation on Testing – Develop Test Cases and Test Plans
Software Quality Assurance in OOAD
SOFTWARE QUALITY ASSURANCE (SQA) is a set of activities for ensuring quality in software engineering processes that ultimately results, or at least gives confidence, in the quality of software products.
SQA includes the following activities:
- Process definition
- Process training
- Process implementation
- Process audit
SQA includes the following processes:
- Project Management
- Project Estimation
- Configuration Management
- Requirements Management
- Software Design
- Software Development
- Software Testing
- Software Deployment
- Software Maintenance
How to perform testing & Quality Assurance in OOAD ?
Testing Object-Oriented Systems
Object Oriented Testing Techniques
Grey Box Testing
- State model based testing − This encompasses state coverage, state transition coverage, and state transition path coverage.
- Use case based testing − Each scenario in each use case is tested.
- Class diagram based testing − Each class, derived class, associations, and aggregations are tested.
- Sequence diagram based testing − The methods in the messages in the sequence diagrams are tested.
Techniques for Subsystem Testing
- The two fundamental methodologies of subsystem testing are −
- Thread based testing − All classes that are expected to understand a solitary utilize case in a subsystem are coordinated and tried.
- Use based testing − The interfaces and administrations of the modules at each level of progressive system are tried. Testing begins from the individual classes to the little modules including classes, slowly to bigger modules, lastly all the significant subsystems.
Categories of System Testing
- Alpha testing − This is completed by the testing group internal the Interaction that creates programming.
- Beta testing − This is completed by select gathering of co-working clients.
- Acceptance testing − This is completed by the client before tolerating the expectations.
Software Quality Assurance
- Development of standards and guidelines
- Production of reports
- Review of quality system
- Correctness − Correctness determines whether the software requirements are appropriately met.
- Usability − Usability determines whether the software can be used by different categories of users (beginners, non-technical, and experts).
- Portability − Portability determines whether the software can operate in different platforms with different hardware devices.
- Maintainability − Maintainability determines the ease at which errors can be corrected and modules can be updated.
- Reusability − Reusability determines whether the modules and classes can be reused for developing other software products.
- Number of scenario scripts
- Number of key classes
- Number of support classes
- Number of subsystems
- Methods per Class − It decides the many-sided quality of a class. In the event that every one of the techniques for a class are thought to be similarly unpredictable, at that point a class with more strategies is more perplexing and along these lines more vulnerable to blunders.
- Inheritance Structure− Systems with a few little legacy grids are more well– organized than systems with a solitary expansive legacy cross section. As a thumb lead, a legacy tree ought not have more than 7 (± 2) number of levels and the tree ought to be adjusted.
- Coupling and Cohesion− Modules having low coupling and high union are thought to be better outlined, as they allow more prominent reusability and viability.
- Response for a Class− It gauges the productivity of the strategies that are called by the occurrences of the class.
- Number of KLOC (Kilo Lines of Code)
- Defect removal efficiency
- Average number of failures detected during testing
- Number of latent defects per KLOC