SoftwareEngg2012 Lecture 03
Transcript of SoftwareEngg2012 Lecture 03
![Page 1: SoftwareEngg2012 Lecture 03](https://reader031.fdocuments.us/reader031/viewer/2022021321/577ccf721a28ab9e788fb9d4/html5/thumbnails/1.jpg)
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 1/44
Software EngineeringBS (Computer Science)
1
Lecture-03Date: 25-02-2012
Dr. S. N Ahsan
![Page 2: SoftwareEngg2012 Lecture 03](https://reader031.fdocuments.us/reader031/viewer/2022021321/577ccf721a28ab9e788fb9d4/html5/thumbnails/2.jpg)
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 2/44
Software Engineering
1. Software Construction
2. Software Management
08.10.2011 Dr. S. N Ahsan, IQRA-University 2
![Page 3: SoftwareEngg2012 Lecture 03](https://reader031.fdocuments.us/reader031/viewer/2022021321/577ccf721a28ab9e788fb9d4/html5/thumbnails/3.jpg)
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 3/44
Software Engineering
08.10.2011 Dr. S. N Ahsan, IQRA-University 3
Quality Focus
Process
Methods
Tools
![Page 4: SoftwareEngg2012 Lecture 03](https://reader031.fdocuments.us/reader031/viewer/2022021321/577ccf721a28ab9e788fb9d4/html5/thumbnails/4.jpg)
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 4/44
Software Common Process Framework
08.10.2011 Dr. S. N Ahsan, IQRA-University 4
A common process framework is established by defining
a small number of framework activities that are applicable
to all software projects, regardless of their size or
complexity.
![Page 5: SoftwareEngg2012 Lecture 03](https://reader031.fdocuments.us/reader031/viewer/2022021321/577ccf721a28ab9e788fb9d4/html5/thumbnails/5.jpg)
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 5/44
A Generic Process Framework1. Communication
2. Planning
3. Modeling4. Construction
5. Deployment
08.10.2011 Dr. S. N Ahsan, IQRA-University 5
![Page 6: SoftwareEngg2012 Lecture 03](https://reader031.fdocuments.us/reader031/viewer/2022021321/577ccf721a28ab9e788fb9d4/html5/thumbnails/6.jpg)
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 6/44
Umbrella Activities
1. Software Project Tracking and Control
2. Risk Management
3. Software Quality Assurance4. Technical Reviews
5. Measurements
6. Software Configuration Management
7. Reusability Management
8. Work Product Preparation and Production
08.10.2011 Dr. S. N Ahsan, IQRA-University 6
![Page 7: SoftwareEngg2012 Lecture 03](https://reader031.fdocuments.us/reader031/viewer/2022021321/577ccf721a28ab9e788fb9d4/html5/thumbnails/7.jpg)
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 7/4408.10.2011
Process Flow
1. Linear Process Flow
2. Iterative Process Flow
3. Evolutionary Process Flow
4. Parallel Process Flow
7Dr. S. N Ahsan, IQRA-University
![Page 8: SoftwareEngg2012 Lecture 03](https://reader031.fdocuments.us/reader031/viewer/2022021321/577ccf721a28ab9e788fb9d4/html5/thumbnails/8.jpg)
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 8/4408.10.2011
Software Process Models Prescriptive Process Models
1. Waterfall model (Royce, 1970) V-Model: The V-model depicts the relationship of quality assurance
actions to the actions associated with the different step of waterfall
model
2. Incremental Process Models
3. Evolutionary Process Models
Prototyping
Spiral model (Boehm, 1988)
4. Concurrent Models
Specialized Process Models
1. Component Based Development2. The Formal Methods Model
3. Aspect Oriented Software Development
The Unified Process
8Dr. S. N Ahsan, IQRA-University
![Page 9: SoftwareEngg2012 Lecture 03](https://reader031.fdocuments.us/reader031/viewer/2022021321/577ccf721a28ab9e788fb9d4/html5/thumbnails/9.jpg)
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 9/44
PRESCRIPTIVE-MODEL
9
![Page 10: SoftwareEngg2012 Lecture 03](https://reader031.fdocuments.us/reader031/viewer/2022021321/577ccf721a28ab9e788fb9d4/html5/thumbnails/10.jpg)
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 10/44
Prescriptive Process Models
Developed to bring order and structure to
the software development process. To get
away from the chaos of most development processes.
But there is a strong balance between order
and chaos. Absolute order means absence of
variability. Absolute chaos makes coordinationand coherence impossible. Thus, a balance is
needed.
08.10.2011 10Dr. S. N Ahsan, IQRA-University
![Page 11: SoftwareEngg2012 Lecture 03](https://reader031.fdocuments.us/reader031/viewer/2022021321/577ccf721a28ab9e788fb9d4/html5/thumbnails/11.jpg)
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 11/4408.10.2011
Waterfall Model
Requirements
Design
Implementation
Maintenance
Testing
11Dr. S. N Ahsan, IQRA-University
![Page 12: SoftwareEngg2012 Lecture 03](https://reader031.fdocuments.us/reader031/viewer/2022021321/577ccf721a28ab9e788fb9d4/html5/thumbnails/12.jpg)
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 12/44
Waterfall Strengths
Easy to understand, easy to use
Provides structure to inexperienced staff
Milestones are well understood
Sets requirements stability Good for management control (plan, staff, track)
Works well when quality is more important than
cost or schedule
08.10.2011 12Dr. S. N Ahsan, IQRA-University
![Page 13: SoftwareEngg2012 Lecture 03](https://reader031.fdocuments.us/reader031/viewer/2022021321/577ccf721a28ab9e788fb9d4/html5/thumbnails/13.jpg)
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 13/44
Waterfall Deficiencies
All requirements must be known upfront The following phase should not start until the
previous phase has finished.
Deliverables created for each phase are
considered frozen – inhibits flexibility Integration is one big bang at the end
Little opportunity for customer to preview thesystem (until it may be too late)
08.10.2011 13Dr. S. N Ahsan, IQRA-University
![Page 14: SoftwareEngg2012 Lecture 03](https://reader031.fdocuments.us/reader031/viewer/2022021321/577ccf721a28ab9e788fb9d4/html5/thumbnails/14.jpg)
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 14/44
When to use the Waterfall Model
Requirements are very well known Product definition is stable
Technology is understood
New version of an existing product Porting an existing product to a new platform.
08.10.2011 14Dr. S. N Ahsan, IQRA-University
![Page 15: SoftwareEngg2012 Lecture 03](https://reader031.fdocuments.us/reader031/viewer/2022021321/577ccf721a28ab9e788fb9d4/html5/thumbnails/15.jpg)
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 15/44
![Page 16: SoftwareEngg2012 Lecture 03](https://reader031.fdocuments.us/reader031/viewer/2022021321/577ccf721a28ab9e788fb9d4/html5/thumbnails/16.jpg)
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 16/44
V-Shaped Strengths
Emphasize planning for verification andvalidation of the product in early stages of
product development
Each deliverable must be testable Project management can track progress by
milestones
Easy to use
08.10.2011 16Dr. S. N Ahsan, IQRA-University
![Page 17: SoftwareEngg2012 Lecture 03](https://reader031.fdocuments.us/reader031/viewer/2022021321/577ccf721a28ab9e788fb9d4/html5/thumbnails/17.jpg)
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 17/44
V-Shaped Weaknesses
Does not easily handle concurrent events
Does not handle iterations or phases
Does not easily handle dynamic changes in
requirements
08.10.2011 17Dr. S. N Ahsan, IQRA-University
![Page 18: SoftwareEngg2012 Lecture 03](https://reader031.fdocuments.us/reader031/viewer/2022021321/577ccf721a28ab9e788fb9d4/html5/thumbnails/18.jpg)
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 18/44
When to use the V-Shaped Model
Excellent choice for systems requiring highreliability – hospital patient control applications
All requirements are known up-front
When it can be modified to handle changingrequirements beyond analysis phase
Solution and technology are known
08.10.2011 18Dr. S. N Ahsan, IQRA-University
![Page 19: SoftwareEngg2012 Lecture 03](https://reader031.fdocuments.us/reader031/viewer/2022021321/577ccf721a28ab9e788fb9d4/html5/thumbnails/19.jpg)
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 19/44
Incremental Development Model
08.10.2011 Dr. S. N Ahsan, IQRA-University 19
![Page 20: SoftwareEngg2012 Lecture 03](https://reader031.fdocuments.us/reader031/viewer/2022021321/577ccf721a28ab9e788fb9d4/html5/thumbnails/20.jpg)
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 20/44
Incremental Model Strengths
Develop high-risk or major functions first
Each release delivers an operational product
Customer can respond to each build
Uses “divide and conquer” breakdown of tasks Lowers initial delivery cost
Initial product delivery is faster
Customers get important functionality early Risk of changing requirements is reduced
08.10.2011 20Dr. S. N Ahsan, IQRA-University
![Page 21: SoftwareEngg2012 Lecture 03](https://reader031.fdocuments.us/reader031/viewer/2022021321/577ccf721a28ab9e788fb9d4/html5/thumbnails/21.jpg)
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 21/44
Incremental Model Weaknesses
Requires good planning and design Requires early definition of a complete and fully
functional system to allow for the definition ofincrements
Well-defined module interfaces are required(some will be developed long before others)
Total cost of the complete system is not lower
08.10.2011 21Dr. S. N Ahsan, IQRA-University
![Page 22: SoftwareEngg2012 Lecture 03](https://reader031.fdocuments.us/reader031/viewer/2022021321/577ccf721a28ab9e788fb9d4/html5/thumbnails/22.jpg)
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 22/44
When to use the Incremental Model
Risk, funding, schedule, program complexity,or need for early realization of benefits.
Most of the requirements are known up-front
but are expected to evolve over time A need to get basic functionality to the market
early
On projects which have lengthy development
schedules
On a project with new technology
08.10.2011 22Dr. S. N Ahsan, IQRA-University
![Page 23: SoftwareEngg2012 Lecture 03](https://reader031.fdocuments.us/reader031/viewer/2022021321/577ccf721a28ab9e788fb9d4/html5/thumbnails/23.jpg)
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 23/44
RAD Model
Rapid Application Development – anincremental model that emphasizes a short
development cycle.
Uses component-based construction method.
Does not work for all projects… particularly
large projects or when project is high risk.
08.10.2011 23Dr. S. N Ahsan, IQRA-University
![Page 24: SoftwareEngg2012 Lecture 03](https://reader031.fdocuments.us/reader031/viewer/2022021321/577ccf721a28ab9e788fb9d4/html5/thumbnails/24.jpg)
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 24/44
RAD Strengths
Reduced cycle time and improved productivitywith fewer people means lower costs
Time-box approach mitigates cost and schedulerisk
Customer involved throughout the completecycle, minimizes risk of not achieving customersatisfaction and business needs
Focus moves from documentation to code(WYSIWYG).
Uses modeling concepts to capture informationabout business, data, and processes.
08.10.2011 24Dr. S. N Ahsan, IQRA-University
![Page 25: SoftwareEngg2012 Lecture 03](https://reader031.fdocuments.us/reader031/viewer/2022021321/577ccf721a28ab9e788fb9d4/html5/thumbnails/25.jpg)
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 25/44
RAD Weaknesses
Accelerated development process must givequick responses to the user
Risk of never achieving closure
Hard to use with legacy systems
Requires a system that can be modularized
Developers and customers must be committed torapid-fire activities in an abbreviated time
frame.
08.10.2011 25Dr. S. N Ahsan, IQRA-University
![Page 26: SoftwareEngg2012 Lecture 03](https://reader031.fdocuments.us/reader031/viewer/2022021321/577ccf721a28ab9e788fb9d4/html5/thumbnails/26.jpg)
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 26/44
When to use RAD
Reasonably well-known requirements
User involved throughout the life cycle
Project can be time-boxed
Functionality delivered in increments High performance not required
Low technical risks
System can be modularized
08.10.2011 26Dr. S. N Ahsan, IQRA-University
![Page 27: SoftwareEngg2012 Lecture 03](https://reader031.fdocuments.us/reader031/viewer/2022021321/577ccf721a28ab9e788fb9d4/html5/thumbnails/27.jpg)
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 27/44
Evolutionary Process Models
Software evolves over time (web pages are a prime example)
Limited version is needed to meet business
pressures. Time does not allow a full and complete system
to be developed.
Evolutionary models are iterative as software
engineers develop increasingly more completeand complex systems
08.10.2011 27Dr. S. N Ahsan, IQRA-University
![Page 28: SoftwareEngg2012 Lecture 03](https://reader031.fdocuments.us/reader031/viewer/2022021321/577ccf721a28ab9e788fb9d4/html5/thumbnails/28.jpg)
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 28/44
Prototyping (Evolutionary Model)
Prototypes are built when goals are general andnot specific.
Prototyping can be used as a standalone process
or by one of the processes presented.
The prototype serves as the first system. Users
get a feel for the actual system and devleopers
get something built quickly.
A prototype is intended for short term use buttoo often they are used much longer.
08.10.2011 28Dr. S. N Ahsan, IQRA-University
![Page 29: SoftwareEngg2012 Lecture 03](https://reader031.fdocuments.us/reader031/viewer/2022021321/577ccf721a28ab9e788fb9d4/html5/thumbnails/29.jpg)
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 29/44
08.10.2011
Prototyping (Evolutionary Model)
Requirements
Implementation
Design
Testing
Design
Implementation
Testing
Maintenance
29Dr. S. N Ahsan, IQRA-University
![Page 30: SoftwareEngg2012 Lecture 03](https://reader031.fdocuments.us/reader031/viewer/2022021321/577ccf721a28ab9e788fb9d4/html5/thumbnails/30.jpg)
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 30/44
Prototyping Strengths
Customers can “see” the system requirements asthey are being gathered
Developers learn from customers
A more accurate end product
Unexpected requirements accommodated
Allows for flexible design and development
Steady, visible signs of progress produced
Interaction with the prototype stimulatesawareness of additional needed functionality
08.10.2011 30Dr. S. N Ahsan, IQRA-University
![Page 31: SoftwareEngg2012 Lecture 03](https://reader031.fdocuments.us/reader031/viewer/2022021321/577ccf721a28ab9e788fb9d4/html5/thumbnails/31.jpg)
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 31/44
Prototyping Weaknesses
Tendency to abandon structured programdevelopment for “code-and-fix” development
Bad reputation for “quick-and-dirty” methods
Overall maintainability may be overlooked The customer may want the prototype
delivered.
Process may continue forever (scope creep)
08.10.2011 31Dr. S. N Ahsan, IQRA-University
![Page 32: SoftwareEngg2012 Lecture 03](https://reader031.fdocuments.us/reader031/viewer/2022021321/577ccf721a28ab9e788fb9d4/html5/thumbnails/32.jpg)
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 32/44
When to use Prototyping
Requirements are unstable or have to beclarified
As the requirements clarification stage of a
waterfall model
Develop user interfaces
Short-lived demonstrations
New, original development
With the analysis and design portions of object-
oriented development.
08.10.2011 32Dr. S. N Ahsan, IQRA-University
![Page 33: SoftwareEngg2012 Lecture 03](https://reader031.fdocuments.us/reader031/viewer/2022021321/577ccf721a28ab9e788fb9d4/html5/thumbnails/33.jpg)
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 33/44
The Spiral Model
An evolutionary model that couples the iterativenature of prototyping with the controlled,
systematic aspects of waterfall model.
Spiral model is often developed in a series of
releases or versions. Is Adobe or Microsoft
working on new releases?
Better for large projects.
08.10.2011 33Dr. S. N Ahsan, IQRA-University
![Page 34: SoftwareEngg2012 Lecture 03](https://reader031.fdocuments.us/reader031/viewer/2022021321/577ccf721a28ab9e788fb9d4/html5/thumbnails/34.jpg)
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 34/44
Spiral Model (Evolutionary Model)
08.10.2011 Dr. S. N Ahsan, IQRA-University 34
![Page 35: SoftwareEngg2012 Lecture 03](https://reader031.fdocuments.us/reader031/viewer/2022021321/577ccf721a28ab9e788fb9d4/html5/thumbnails/35.jpg)
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 35/44
08.10.2011
Risk analysis
Risk analysis
Risk analysis
Risk analysis Proto-
type 1
Prototype 2
Prototype 3Opera-
tional protoype
Concept of Operation
Simulations, models, benchmarks
S/Wrequirements
Requirementvalidation
DesignV&V
Productdesign Detailed
design
Code
Unit test
IntegrationtestAcceptance
testService Develop, verifynext-level product
Evaluate alternativesidentify, resolve risks
Determine objectivesalternatives and
constraints
Plan next phase
Integrationand test plan
Development plan
Requirements planLife-cycle plan
REVIEW
Spiral Model (Evolutionary Model)
35Dr. S. N Ahsan, IQRA-University
![Page 36: SoftwareEngg2012 Lecture 03](https://reader031.fdocuments.us/reader031/viewer/2022021321/577ccf721a28ab9e788fb9d4/html5/thumbnails/36.jpg)
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 36/44
Spiral Model Strengths
Provides early indication of insurmountablerisks, without much cost
Users see the system early because of rapid
prototyping tools
Critical high-risk functions are developed first
The design does not have to be perfect
Users can be closely tied to all lifecycle steps
Early and frequent feedback from users
Cumulative costs assessed frequently
08.10.2011 36Dr. S. N Ahsan, IQRA-University
![Page 37: SoftwareEngg2012 Lecture 03](https://reader031.fdocuments.us/reader031/viewer/2022021321/577ccf721a28ab9e788fb9d4/html5/thumbnails/37.jpg)
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 37/44
Spiral Model Weaknesses
Time spent for evaluating risks too large for
small or low-risk projects
Time spent planning, resetting objectives, doingrisk analysis and prototyping may be excessive
The model is complex
Risk assessment expertise is required
Spiral may continue indefinitely
Developers must be reassigned during non-
development phase activities May be hard to define objective, verifiable
milestones that indicate readiness to proceedthrough the next iteration
08.10.2011 37Dr. S. N Ahsan, IQRA-University
![Page 38: SoftwareEngg2012 Lecture 03](https://reader031.fdocuments.us/reader031/viewer/2022021321/577ccf721a28ab9e788fb9d4/html5/thumbnails/38.jpg)
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 38/44
When to use Spiral Model
When creation of a prototype is appropriate When costs and risk evaluation is important
For medium to high-risk projects
Long-term project commitment unwise because
of potential changes to economic priorities Users are unsure of their needs
Requirements are complex
New product line
Significant changes are expected (research andexploration)
08.10.2011 38Dr. S. N Ahsan, IQRA-University
![Page 39: SoftwareEngg2012 Lecture 03](https://reader031.fdocuments.us/reader031/viewer/2022021321/577ccf721a28ab9e788fb9d4/html5/thumbnails/39.jpg)
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 39/44
SPECIALIZED PROCESS MODELS
39
![Page 40: SoftwareEngg2012 Lecture 03](https://reader031.fdocuments.us/reader031/viewer/2022021321/577ccf721a28ab9e788fb9d4/html5/thumbnails/40.jpg)
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 40/44
Component Based Development
COTS or Commercial Off-The-Shelfcomponents are becoming more available.
Most (not all) COTS components have targeted
functionality with good interfaces that enable
the component to be integrated.
This approach incorporates many of the aspects
of the spiral model.
08.10.2011 40Dr. S. N Ahsan, IQRA-University
![Page 41: SoftwareEngg2012 Lecture 03](https://reader031.fdocuments.us/reader031/viewer/2022021321/577ccf721a28ab9e788fb9d4/html5/thumbnails/41.jpg)
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 41/44
Formal Methods Development Model
Formal mathematical specification of thesoftware.
Specify, develop and verify by rigourous math
notation.
Eliminates ambiguity, incompleteness, and
inconsistency.
Used more where safety-critical software is
developed, e.g., aircraft avionics, medicaldevices, etc.
08.10.2011 41Dr. S. N Ahsan, IQRA-University
![Page 42: SoftwareEngg2012 Lecture 03](https://reader031.fdocuments.us/reader031/viewer/2022021321/577ccf721a28ab9e788fb9d4/html5/thumbnails/42.jpg)
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 42/44
Aspect-Oriented SW Development
Nearly all SW has localized features, functionsand information content.
User or customer concerns or needs must be
included. These can be high-level concerns like
security or lower-level such as marketing
business rules or systemic such as memory
management.
08.10.2011 42Dr. S. N Ahsan, IQRA-University
![Page 43: SoftwareEngg2012 Lecture 03](https://reader031.fdocuments.us/reader031/viewer/2022021321/577ccf721a28ab9e788fb9d4/html5/thumbnails/43.jpg)
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 43/44
Crosscutting Concerns
AOP addresses behaviors that span many, often
unrelated, modules. Core Concerns:
◦ Primary core functionality.
◦ Central functionality of a module.
Crosscutting Concerns:◦ System wide concerns that span multiple
modules.
◦ Cuts across the typical division of
responsibility. OOP creates a coupling between core and
crosscutting concerns.
AOP aims to modularize crosscutting concerns.
08.10.2011 43Dr. S. N Ahsan, IQRA-University
![Page 44: SoftwareEngg2012 Lecture 03](https://reader031.fdocuments.us/reader031/viewer/2022021321/577ccf721a28ab9e788fb9d4/html5/thumbnails/44.jpg)
8/12/2019 SoftwareEngg2012 Lecture 03
http://slidepdf.com/reader/full/softwareengg2012-lecture-03 44/44
Aspects
In AOP crosscutting concerns are implemented in
aspects instead of fusing them into core modules.
Aspects are an additional unit of modularity.
Aspects can be reused.
By reducing code tangling it makes it easier tounderstand what the core functionality of a
module is.
An “aspect weaver” takes the aspects and the core
modules and composes the final system.