SEbr20cse
Syllabus
UNIT I: The Nature of Software, The Unique Nature of WebApps, Software Engineering, The
Software Process, Software Engineering Practice, Software Myths. A Generic Process
Model, Process Assessment and Improvement, Prescriptive Process Models, Specialized
Process Models, The Unified Process, Personal and Team Process Models, Process
Technology.
T1: Chapters 1, 2.
UNIT II: Agility, Agility and the Cost of Change, Agile Process, Extreme Programming (XP), Other
Agile Process Models, A Tool Set for the Agile Process, Software Engineering Knowledge,
Core Principles, Principles That Guide Each Framework Activity, Requirements
Engineering, Establishing the Groundwork, Eliciting Requirements, Developing Use Cases,
Building the Requirements Model, Negotiating Requirements,
Validating Requirements.
T1: Chapters 3, 4, 5.
UNIT III: Requirements Analysis, Scenario-Based Modeling, UML Models That Supplement the Use
Case, Data Modeling Concepts, Class-Based Modeling, Requirements Modeling Strategies,
Flow-Oriented Modeling, Creating a Behavioral Model, Patterns for
Requirements Modelling, Requirements Modeling for WebApps.
T1: Chapters 6, 7.
UNIT IV: Design within the Context of Software Engineering, The Design Process, Design Concepts,
The Design Model, Software Architecture, Architectural Genres, Architectural Styles,
Assessing Alternative Architectural Designs, Architectural Mapping Using Data Flow,
Components, Designing Class-Based Components, Conducting Component-Level Design,
Component-Level Design for WebApps, Designing Traditional Components,
Component-Based Development.
T1: Chapters 8, 9, 10.
UNIT V: The Golden Rules, User Interface Analysis and Design, Interface Analysis, Interface Design
Steps, WebApp Interface Design, Design Evaluation, Elements of Software Quality
Assurance, SQA Tasks, Goals & Metrics, Statistical SQA, Software Reliability, A Strategic
Approach to Software Testing, Strategic Issues, Test Strategies for Conventional Software,
Test Strategies for Object-Oriented Software, Test Strategies for WebApps, Validation
Testing, System Testing, The Art of Debugging, Software Testing Fundamentals, Internal
and External Views of Testing, White-Box Testing, Basis Path
Testing
T1: Chapters 11(11.1 to 11.6), 16(16.2 to 16.6), 17(17.1 to 17.8), 18(18.1 to 18.4)
Note: T1 = Text Book_1 in the list of Text books given below
R1 = Reference Book_1 in the list of Reference books.
Text Books/ Weblinks/Material
Summary Notes PDF- units 3b, 4, 5 - Link
Typed Version Notes PDF -Link
(Credits to Mr. Manas Sir, ASST.PROF. CSE)
Hand Written Notes PDF - Link
TEXT BOOKS
1. Software Engineering a practitioner‘s approach, Roger S. Pressman, Seventh Edition, McGraw
Hill Higher Education. PDF Link
2. Software Engineering, Ian Sommerville, Ninth Edition, Pearson.
REFERENCE BOOKS
1. Software Engineering, A Precise Approach, PankajJalote, Wiley India, 2010.
2. Software Engineering, Ugrasen Suman, Cengage.
WEB RESOURCES
1. Dr. B. Lavanya
https://onlinecourses.swayam2.ac.in/cec20_cs07/preview (Swayam Enrollment Required)
2. From Prof. Rajib Mall
https://nptel.ac.in/courses/106105182 for 2024-25 AY enrollment only
3. Prof. N. L. Sarda
Mostly Repeated Previous Paper Questions for Class Test
I: s/w myths, Unique nature, Prescriptive process models, PSP & TSP
II: XP, other Agile process Models, Developing use case
III_part1: Req-Analysis, UML Models, Data Modelling Concepts
Summary Notes PDF- units 3b, 4, 5 - Link
Unit-III _part2:
@ CRC modeling* (read Class-based modeling; This topic covers CRC)
@ Flow model
@ Behavioral model*
@ Requirement modeling for WebApps*
Unit-IV:
@ Design Concepts*
@Architectural Styles**
@ Conduct component-level design (basic design principles)*
@ Coupling, Cohesion
Unit-V:
@ Golden Rules**
@ Test strategies for conventional Apps
@ Art of Debugging*
@ White-box testing*
@ Basis path testing*
.png)
.png)
.png)
Previous Papers
Four Question Papers PDF - Link
Paper-1:
UNIT-I
a) Illustrate Generic Software process model
b)Write the characteristics of WebApps
a)Illustrate Unified Process in software development.
b)What are software myths, and how do they affect the perception of software engineering?
UNIT-II
a)Describe the Extreme Programming (XP) methodology and its key features
b) What is the role of requirements engineering in Agile methodologies?
a) Write elicitation and validation of requirements of agile process model.
b) Explain the concept of 'Agility and the Cost of Change in software development.
UNIT-III
a) Define UML models and their role in supplementing use cases.
b) What are the key strategies used in requirements modeling for WebApps?
a)Discuss the importance of class-based modeling in requirements analysis.
b) Explain the concept of creating a behavioral model in software engineering.
UNIT-IV
a) Discuss the relationship between design concepts and the software design model.
b) Explain the role of architectural styles in software architecture.
a) Describe the process of component-level design for WebApps.
b) What is component-based development and its significance in software engineering?
UNIT-V
a) Discuss the 'Golden Rules of user interface design and their application in WebApp design.
b) Explain the strategic issues in software testing for conventional software. OR
a) Explain about Unit testing in-detail.
b) What is white-box testing and black-box testing?
Paper-2:
UNIT-I
a) Explain about overview of the Software process.
b) Explain water fall model with a diagram
b) Explain the perspective process model with example.
UNIT-II
a) Explain about Agile process with suitable example,
b) Explain software requirements document.
a)Discuss a tool set for agile process.
b)Distinguish between negotiating and validating Requirements?
UNIT-III
a) What is meant by software design? Explain the traditional approach.
b) Explain the need of software requirement specification.
a) What is meant by cohesion? Explain different types of cohesion.
b) Explain Requirement gathering and Analysis.
UNIT-IV
a)Explain the steps in software documentation and give its uses.
b) Distinguish between white box testing and black box testing. OR
a) Explain the general problems associated with testing
b) Discuss about the Software Quality Assurance.
UNIT-V
a) Explain various aspects of the configuration management.
b) Explain the basic issues in software Reuse.
a) Explain software reuse in detail.
b) Explain the cost of software maintenance.
Paper-3:
UNIT-I
a) Compare and contrast. waterfall model and spiral model.
b) Define process model. What are evolutionary process models? Explain in detail
a) What are software myths? Explain in detail.
b)Define software engineering. Explain about process patterns.
UNIT-II
a) Define agility and agile team with different Characteristics of Agility.
b) How Extreme Programming used in a Nutshell.
a) Explain briefly the requirement engineering process with neat sketch and ?
b)Describe each process with an example Distinguish between negotiating and validating Requirements
UNIT-III
a)Explain the use of UML, for object-oriented design.
b)Explain briefly about Flow Oriented Modeling
a) Demonstrate the steps performed by analyst in creating a behavioral model.
b)Explain in detail Requirements Modeling for WebApps.
UNIT-IV
a) Explain the design process in software engineering and its levels.
b)Describe in detail about to design a traditional components
a)What are architectural styles and patterns? Describe some common architectural styles and patterns used in software development.
b) Compare and contrast the design steps for transaction mapping and steps for transform mapping.
UNIT-V
a)Describe golden rules for interface design.
b)What is unit testing? Why is it important? Explain the unit test consideration and test procedure.
a)Demonstrate about Test Strategies for WebApps
b) Explain Integration & debugging activities
Paper-4:
UNIT-I
a) Describe the main activities involved in the Waterfall model
b) Compare and contrast the Waterfall model with the Spiral model.
a) Explain the significance of process assessment and improvement in software engineering
b)Discuss specialized process models and their applications.
UNIT-II
a)Define the Agile Process Model and explain its core principles.
b) Discuss the main features of Extreme Programming (XP).
a) Discuss the differences between eliciting and validating requirements.
b) Explain the process of developing use cases in requirements engineering
UNIT-III
a) Illustrate the key components of the Analysis Model
b) Explain data modeling concepts and their importance.
a) Describe the process of creating a behavioral model in requirements modeling
b) Illustrate the flow-oriented modeling technique.
UNIT-IV
a) Describe the main stages of the Design Process in software engineering.
b) Explain the significance of the Design Model.
a)Describe the approach to component-based development.
b) Discuss the concept of architectural genres and their impact on software design
UNIT V
a) Explain the principles of User Interface Analysis and Design.
b) Illustrate Basis Path Testing with examples.
a) Explain the various test strategies for web applications.
b) Discuss the importance of validation testing and system testing in software development.
Unit-1: Software and Software Engineering; Process Models;
Just for Idea only (NOT IN SYLLABUS)
Weblink for other s/w engg tools: LINK
Assignment Unit-1
- Discuss the nature of software. K2
- Explain in Detail about Evolutionary process model. K2
- Explain the importance of Unified process. K2
- Outline the Umbrella activities needed for a software process. K2
- Analyze all the software Myths and realities. K4
- Explain in Detail about Incremental process model. K2
- Discuss about the Unique Nature of Webapps. K2
- Explain regarding Personal and team process models. K2
- Explain waterfall model for software development. K2
Difficulty Levels: Level-I =Easy; Level-II= Moderate; Level-III=Difficult
Level-I=Q1,2,3; Level-II =Q4,5,6; Level-III = Q7,8,9;
----------------------
Other Questions to study:
10) Explain the significance of process assessment and improvement in software engineering
11)Discuss specialized process models and their applications.
Quiz Unit-1
1. With respect to time and compared to ideal case, Software (actual) failure rate _____________.
(A) increases due to side effects (B) decreases (C) contant (D) zero
2. WebApps present information based on _________.
(A) text (B) limited graphics (C) both (A) and (B) (D) they don't exist
3. Legacy software is _________.
(A) latest (B) branded (C) both (A) and (B) (D) oldest (E) both (B) and (D)
4. Software Engineering layers (from top to bottom) are _________.
Tools =1, quality focus=2, process=3, methods=4
(A) 3,1,4,2 (B) 4,1,2,3 (C) 2,4,1,3 (D) 1,4,3,2
5. The given statement is:____________
Statement: If I decide to outsource the software project to a third party, I can just relax and let that firm build it.
Myth =1, Reality=2, Customer=3, Management=4, Practitioner=5
(A)1,3 (B) 1, 5 (C) 1, 4 (D) 2, 4 (E)2, 5 (F)2, 3
6. Incremental process models are _________ in nature and produce working versions of software quite rapidly.
(A) non-cooperative (B) iterative (C) inactive (D) insensitive
KEY: 1-A, 2-C, 3-E, 4-D, 5-B, 6-B
Unit-2: Agility, Principles that Guide Practice, Understanding Requirements
Assignment Unit-2
- What is the purpose of Agile Process Model? Discuss about Extreme Programming?
- Illustrate the different Elements of Analysis model?
- Clearly Discuss about The Principles That Guide Each Framework Activity
- Discuss about Software Engineering Knowledge and Core Principles?
- Explain about Requirement Elicitation.
- Discuss briefly about Establishing the Groundwork
- Demonstrate about different Agile Process Models.
- Distinguish between negotiating and validating Requirements?
- Give a Brief note on Building the Requirements Model
Difficulty Levels: Level-I =Easy; Level-II= Moderate; Level-III=Difficult
Level-I=Q1,2,3; Level-II =Q4,5,6; Level-III = Q7,8,9;
----------------------
Other Questions to study:
Quiz Unit-2
1. Ability to adpt to the changes _____________.
(A) Agility (B) process (C) task (D) activity
2.As time progresses, Development cost for conventional software processes is ________ than an agile process.
(A) lesser (B) zero (C) higher (D) unpredictable
3. Agile software process must adapt __________.
(A) not needed (B) decremented (C) derivated (D) incrementally
4. In order to achieve effective communication between software engineers and other stakeholders. ________ emphasizes close, yet informal (verbal) collaboration between customers and developers
(A) conventional process (B) legacy (C) formal(Word,PPT) (D) informal(Verbal)
5. Feedback is derived from three sources: the implemented software itself, the customer, and other ____________ members
(A) drivers (B) software team (C) third party D) unnecessary stakeholders.
6. XP Process starts with listening requirements that create _____________
(A) project itslef (B) stories (C) process framework (D) coding
KEY: 1-A, 2-C, 3-D, 4-D, 5-B, 6-B
Lecture Notes: Unit-3: Requirements Modeling { (Scenarios, Information, Analysis Classes), (Flow, Behavior Patterns, WebApps)}
(3.2a) Requirements Modeling Strategies:
Structured Analysis: focuses on data objects, transformation as they flow through the system.
Object-oriented analysis: focuses on definition of classes and their collaboration.
(3.2b)Flow-oriented Modeling:
DFD = Data Flow Diagram --> Level 0, Level 1, Level 2
Terminology of DFD: bubble, primary input and primary output, label arrows and bubbles, refine one bubble at a time.
Level_0 = single bubble and relations
Level_1 = basic bubble split into two or more detailed blocks
Level_2 = each bubble must be the simplest function
(3.2c) Creating a behavioral model:
1. identify events
2. state representations
3. sequence diagrams
4. build a state diagram for the system
5. review the model to verify accuracy and consistency.
Behv Model1: State diagram
Behv Model2: Sequence diagram
(3.2d) Patterns for Requirements Modeling:
* Software pattern = mech(cap domain knowledge); This can be reapplied to a new problem.
* domain knowledge applied to a problem in same domain
* domain knowledge captured by a pattern, applied to a completely different application domain.
So, Behavioral models = (i) State Diagram (ii) Sequence diagram in UML
(a) Discovering Analysis Patterns=> The requirements model is comprised of a wide variety of elements: scenario-based (use cases), data-oriented (the data model), class-based, flow-oriented, and behavioral.
(b) Requirements Pattern Example: Actuator-Sensor
Pattern Name: Actuator-Sensor
Intent: Specify various kinds of sensors and actuators in an embedded system.
Motivation: Embedded systems usually have various kinds of sensors and actuators.
Constraints: Each passive sensor, each active sensor, each actuator duty/ duties are to be mentioned. duty = function/ task
Applicability: Useful in any system in which multiple sensors and actuators are present.
Structure:
Behavior:
Participants:
• PassiveSensor abstract: Defines an interface for passive sensors.
• PassiveBooleanSensor: Defines passive Boolean sensors.
• PassiveIntegerSensor: Defines passive integer sensors.
• PassiveRealSensor: Defines passive real sensors.
• ActiveSensor abstract: Defines an interface for active sensors.
• ActiveBooleanSensor: Defines active Boolean sensors.
• ActiveIntegerSensor: Defines active integer sensors.
• ActiveRealSensor: Defines active real sensors.
• Actuator abstract: Defines an interface for actuators.
• BooleanActuator: Defines Boolean actuators.
• IntegerActuator: Defines integer actuators.
• RealActuator: Defines real actuators.
• ComputingComponent: The central part of the controller; it gets the data from the sensors and computes the required response for the actuators.
• ActiveComplexSensor: Complex active sensors have the basic functionality of the abstract ActiveSensor class, but additional, more elaborate, methods and attributes need to be specified.
• PassiveComplexSensor: Complex passive sensors have the basic functionality of the abstract PassiveSensor class, but additional, more elaborate, methods and attributes need to be specified.
• ComplexActuator: Complex actuators also have the base functionality of the abstract Actuator class, but additional, more elaborate methods and attributes need to be specified.
Collaborations: objects and classes interact with one another and how each carries out its responsibilities.
ComputingComponent <----->---> PassiveSensor
ComputingComponent <---<-----> ActiveSensor (They send a life tick at least once during a specified time frame)
ComputingComponent <-------->-----> actuator
ComputingComponent <-----query, set the operation state of the sensors and actuators
Ex: operation state =zero, then the error is sent to the FaultHandler (a class that contains methods for handling error messages) like recovery mechanism or a backup device. If recovery fails then last known value for the sensor or the default value used.
• The ActiveSensors offer methods to add or remove the addresses or address ranges of the components that want to receive the messages in case of a value change.
Consequences:
* Sensor and actuator classes have a common interface.
* Class decides whether or not to accept the message.
Ex: if a value of an actuator is set above a maximum value, then the actuator class may not accept the message, or it might use a default maximum value.
* The complexity of the system is potentially reduced because of the uniformity of interfaces for actuators and sensors.
(3.2e) Requirements Modeling for WebApps:
1. How much analysis enough? i.e., number of stake-holders, degree to which stakeholders worked, WebApp (size, its success effecting Org). '
2. Requirements modeling input: PASSWORD=maximum and minimum length, VIDEO= Resolution, Alarm, Pan and Zoom, GEO-Tag,
Natural language description, rough outlines, sketches, and other formal representations.
3. Requirements modeling output:
Content model: (text, graphics (image, video, audio....))
Interaction model: manner in which users can interact with the WebApp
Functional model: operations that wll be applied to WebApp
Navigation model: navigation strategy of WebApp
Configuration model: environment in which WebApp resides
Assignment Unit-3
- Explain in detail Requirements Analysis.
- Give a brief note on Class-Responsibility-Collaborator (CRC) Modeling
- Explain in detail Patterns for Requirements Modelling
- Discuss in detail Data Modeling Concepts.
- Explain in detail Requirements Modeling for WebApps.
- Explain about Creating a Behavioral Model
- Explain in detail Requirements Modeling Strategies
- Demonstrate about Flow-Oriented Modeling
- Discuss in detail about UML Models That Supplement the Use Case
mid-1 Assignment Q: 1, 3, 4, 9; Two batches= {(1,3),(4,9)}
mid-2 Assignment Q: 2, 5, 6, 7, 8; Two Batches = {(2, 5, 6), (6, 7, 8)}
Difficulty Levels: Level-I =Easy; Level-II= Moderate; Level-III=Difficult
Level-I=Q1,2,3; Level-II =Q4,5,6; Level-III = Q7,8,9;
----------------------
Other Questions to study:
Quiz Unit-3
1. ________-based models of requirements from the point of view of various system “actors
(A) Scenario (B) process (C) task (D) activity
2. ______-oriented models that represent the functional elements of the system and how they transform data as it moves through the system
(A) Model (B) Process (C) Flow (D) Design
3. ________ models that depict how the software behaves as a consequence of external “events”
(A) Flow (B) Behavioral (C) Scenario (D) Activity
4. UML = __________
(A) Unidentified Modeling Language (B) Unique Modeling Language (C) Unified Markup Language (D) Unified Modeling Language
5. A ________ is a representation of composite information that must be understood by software
(A) sentence (B) data object (C) plan (D) process
6. ________ describe a class that has been selected for inclusion in the requirements model.
(A) Process (B) Attributes (C) Task (D) Activity
7. CRC = _______ _________ ______
(A) Class-Responsibility-Collaborator (B) Concept-Responsibility-Collaborator (C) Class-Request-Collaborator (D) Clas-Responsibility-Clearance
8. DFD
(A) disk flow diagram (B) data flaw diagram (C) data flow diagram (D) disk flaw diagram
9. PSPEC
(A) plan specification (B) process specification (C) process speculation (D) plan speculation
10. The _______model indicates how software will respond to external events or stimuli.
(A) behavioral (B) unity (C) blackbox (D) task
11. A _________ state is simply the current status of all of an object’s attributes
(A) complex (B) simple (C) active (D) passive
12. An _______ occurs concurrently with the state transition or as a consequence of it and generally involves one or more operations (responsibilities) of the object
(A) assessment (B) activity (C) action (D) assurance
13. ______________ in UML, indicates how events cause transitions from object to object
(A) simple diagram (B) sequence diagram (C) process diagram (D) selection diagram
14. A ___________is a pattern that describes a small set of coherent use cases that together describe a basic generic application
(A) semantic analysis pattern (B) semantic assurance pattern (C) systematic analysis pattern (D) systematic available pattern
KEY: 1-A, 2-C, 3-B, 4-D, 5-B, 6-B, 7-A, 8-C, 9-B, 10-A, 11-D, 12-C, 13-B, 14-A
Lecture Notes: Unit-4: Design Concepts, Architectural Design, Component-level Design
TOPICS:
Design Concepts
4.1 Design within the Context of Software Engineering
4.2 The Design Process
4.3 Design Concepts
4.4 The Design Model
Architectural Design
4.5 Software Architecture
4.6 Architectural Genres
4.7 Architectural Styles
4.8 Assessing Alternative Architectural Designs
4.9 Architectural Mapping Using Data Flow
Component-level Design
4.10 Components
4.11 Designing Class-Based Components
4.12 Conducting Component-Level Design
4.13 Component-Level Design for Web Apps
4.14 Designing Traditional Components
4.15 Component-Based Development.
4.1 Design within the Context of Software Engineering
- why is design so important? => Answer is a single word—quality.
- interface design => software communicates with systems(interoperation) and humans (who use it).
- The architectural design => major structural elements of s/w, the architectural styles, design patterns, constraints
- The data/class => transforms class models to design class realizations (the imp data structures to implement the s/w)
- The component-level design = structural elements of the software architecture procedural description of software components.
4.2 The Design Process
Quality Guidelines
1. A design should exhibit an architecture that:
(a) recognizable architectural styles or patterns
(b) is composed of components that exhibit good design characteristics
(c) thereby facilitating implementation and testing.
2. A design = modular (logically partitioned into elements or subsystems)
3. A design = contain distinct representations of data, architecture, interfaces, and components
4. design = data structures appropriate for the classes to be implemented
5. A design should lead to components that have independent functional characteristics.
6. A design should lead to interfaces that reduce the complexity of connections and with the external environment.
7. A design = derived using a repeatable method that is driven by information obtained during software requirements analysis.
8. A design = notation that effectively communicates its meaning.
Quality Attributes
- Functionality is assessed by evaluating the feature set, capabilities, generality and security of the overall system.
- Usability is assessed by considering human factors, overall aesthetics, consistency, and documentation.
- Reliability is evaluated by measuring the frequency and severity of failure, the accuracy of output results, the mean-time-to-failure (MTTF), the ability to recover from failure, and the predictability of the program.
- Performance is measured by considering processing speed, response time, resource consumption, throughput, and efficiency.
- Supportability combines the ability to extend the program (extensibility), adaptability, serviceability—these three attributes represent a more common term, maintainability—and in addition, testability, compatibility, configurability, the ease with which a system can be installed, and the ease with which problems can be localized.
The Evolution of Software Design
Refining software structures in a topdown manner
software design =emphasis on software architecture + the design patterns
Number of design methods, growing out of the work just noted, are being applied throughout the industry
Common characteristics:
(a) requirements model design representation
(b) notation = represent functional components and their interfaces
(c) shortcuts for refinement and partitioning
(d) guidelines for quality assessment
4.3 Design Concepts (AAPS MIFR AROD)
Abstraction: * A procedural abstraction refers to a sequence of instructions that have a specific and limited function
* A data abstraction is a named collection of data that describes a data object
* Data Abstraction = Door; then procedural abstraction= open
Architecture:
* architecture is the structure or organization of program components (modules)
* Components = major system elements set of architectural patterns enables a software engineer to solve common design problems
* Structural models = architecture as an organized collection of program components
* Dynamic models = behavioral aspects of system config change due to external events.
* Process models= focus on the design of the business or technical process of the system
* Functional models = represent the functional hierarchy of a system
* Architectural Description Languages (ADLs) = developed to represent these models
Patterns:
* A pattern is a named nugget of insight which conveys the essence of a proven solution to a recurring problem within a certain context amidst competing concerns
* The intent of each design pattern is to provide a description that enables a designer to determine:
(1) whether the pattern is applicable to the current work,
(2) whether the pattern can be reused (hence, saving design time), and
(3) whether the pattern can serve as a guide for developing a similar, but functionally or structurally different pattern
Separation of Concerns:
* A concern is a feature or behavior that is specified as part of the requirements model for the software
* Separation of concerns is a design concept that suggests that any complex problem can be more easily handled if it is subdivided into pieces that can each be solved and/or optimized independently
Modularity:
* Software is divided into separately named and addressable components, sometimes called modules, that are integrated to satisfy problem requirements.
Information Hiding:
* modules should be specified and designed so that information (algorithms and data) contained within a module is inaccessible to other modules that have no need for such information
Functional Independence:
* Independent modules are easier to maintain (and test) because secondary effects caused by design or code modification are limited, error propagation is reduced
* Cohesion is an indication of the relative functional strength of a module.
* Coupling is an indication of the relative interdependence among modules
Refinement:
* Refinement helps to reveal low-level details as design progresses. It is actually a process of elaboration
* Abstraction enables to specify procedure and data internally but suppress the need for “outsiders” to have knowledge of low-level details
Aspects:
* If requirements analysis is done, then a set of “concerns” is uncovered.
* An aspect is a representation of a crosscutting concern.
* Req-A, Req-B: B can not be satisfied w/o taking A into consideration; => A crosscuts B.
Refactoring:
* Refactoring is a reorganization technique that simplifies the design (or code) of a component without changing its function or behavior
OOD Concepts:
* OO design concepts such as classes and objects, inheritance, messages, and polymorphism
Design Classes:
* design classes that refine the analysis classes by providing design detail that will enable the classes to be implemented and implement a software infrastructure that supports the business solution.
User interface classes define all abstractions that are necessary for human computer interaction (HCI). In many cases, HCI occurs within the context of a metaphor (e.g., a checkbook, an order form, a fax machine), and the design classes for the interface may be visual representations of the elements of the metaphor.
Business domain classes are often refinements of the analysis classes defined earlier. The classes identify the attributes and services (methods) that are required to implement some element of the business domain.
Process classes implement lower-level business abstractions required to fully manage the business domain classes.
Persistent classes represent data stores (e.g., a database) that will persist beyond the execution of the software.
System classes implement software management and control functions that enable the system to operate and communicate within its computing environment and with the outside world.
Complete and sufficient: A design class should be the complete encapsulation of all attributes and methods that can reasonably be expected (based on a knowledgeable interpretation of the class name) to exist for the class
Primitiveness: Methods associated with a design class should be focused on accomplishing one service for the class. Once the service has been implemented with a method, the class should not provide another way to accomplish the same thing.
High cohesion: A cohesive design class has a small, focused set of responsibilities and single-mindedly applies attributes and methods to implement those responsibilities.
Low coupling: Within the design model, it is necessary for design classes to collaborate with one another. However collaboration should be kept to an acceptable minimum
Design class for FloorPlan and composite aggregation for the class:
4.4 The Design Model
The design model can be viewed in two different dimensions:
abstraction dimension represents the level of detail as each element
Data Design Elements
a.Like other software engineering activities, data design (sometimes referred to as data architecting) creates a model of data and/or information that is represented at a high level of abstraction (the customer/user’s view of data).
b.This data model is then refined into progressively more implementation-specific representations that can be processed by the computer-based system.
c.At the program component level, the design of data structures and the associated algorithms required to manipulate them is essential to the creation of high-quality applications
d.At the application level, the translation of a data model (derived as part of requirements engineering) into a database is pivotal to achieving the business objectives of a system.
e.At the business level, the collection of information stored in disparate databases and reorganized into a “data warehouse” enables data mining or knowledge discovery that can have an impact on the success of the business itself.
Architectural Design Elements
a. Architectural design elements give us an overall view of the software.
b. The architectural model is derived from three sources:
(1) information about the application domain for the software to be built;
(2) specific requirements model elements such as data flow diagrams or analysis classes, their relationships and collaborations for the problem at hand; and
(3)the availability of architectural styles and patterns.
c. The architectural design element is usually depicted as a set of interconnected subsystems, often derived from analysis packages within the requirements model.
d. Each subsystem may have it’s own architecture.
Interface Design Elements
a. The interface design elements for software depict information flows into and out of the system and how it is communicated among the components defined as part of the architecture.
b.There are three important elements of interface design:
(1) the user interface (UI);
(2) external interfaces to other systems, devices, networks, or other producers or consumers of information; and
(3) internal interfaces between various design components.
c. These interface design elements allow the software to communicate externally and enable internal communication and collaboration among the components that populate the software architecture.
d. UI design (increasingly called usability design) is a major software engineering action. Usability design incorporates aesthetic elements (e.g., layout, color, graphics, interaction mechanisms), ergonomic elements.(e.g., information layout and placement, metaphors, UI navigation), and technical elements (e.g., UI patterns, reusable components).
Component-Level Design Elements
a.The component-level design for software fully describes the internal detail of each software component. To accomplish this, the component-level design defines data structures for all local data objects and algorithmic detail for all processing that occurs within a component and an interface that allows access to all
component operations (behaviors).
b.The design details of a component can be modeled at many different levels of abstraction. A UML activity diagram can be used to represent processing logic. Detailed procedural flow for a component can be represented using either pseudocode or some other diagrammatic form (e.g., flowchart or box diagram). Algorithmic structure follows the rules established for structured programming (i.e., a set of constrained procedural constructs).
Deployment-Level Design Elements
Deployment-level design elements indicate how software functionality and subsystems will be allocated within the physical computing environment that will support the software.
For example, the elements of the SafeHome product are configured to operate within three primary computing environments—a home-based PC, the SafeHome control panel, and a server housed at CPI Corp. (providing Internet-based access to the system).
4.5 Software Architecture:
* What is Software Architecture? The software architecture of a program comprise software components
*Why Architecture is important?
The architecture=representation (only, but not program) enabling:
#enabler for communication between all parties (stakeholders)
# early design decisions that will have a profound impact on all software engineering work
# define model that details how its components work together
• Architectural Descriptions:
#Representations of software architecture are an enabler for communication between all
#architectural description is actually a set of work products that reflect different views of the system parties (stakeholders) interested in the development of a computer-based system.
• Architectural Decisions: architectural decisions themselves can be considered to be one view of the architecture.
4.6 Architectural Genres:
=> specific architectural approach to the structure that must be built ==> each genre represents a unique challenge
Following are architectural genres for software-based systems:
• Artificial intelligence—Systems that simulate or augment human cognition, locomotion, or other organic processes.
• Commercial and nonprofit—Systems that are fundamental to the operation of a business enterprise.
• Communications—Systems that provide the infrastructure for transferring and managing data, for connecting users of that data, or for presenting data at the edge of an infrastructure.
• Content authoring—Systems that are used to create or manipulate textual or multimedia artifacts.
• Devices—Systems that interact with the physical world to provide some point service for an individual.
• Entertainment and sports—Systems that manage public events or that provide a large group entertainment experience.
• Financial—Systems that provide the infrastructure for transferring and managing money and other securities.
• Games—Systems that provide an entertainment experience for individuals or groups.
• Government—Systems that support the conduct and operations of a local, state, federal, global, or other political entity.
• Industrial—Systems that simulate or control physical processes.
• Legal—Systems that support the legal industry.
• Medical—Systems that diagnose or heal or that contribute to medical research.
• Military—Systems for consultation, communications, command, control, and intelligence (C4I) as well as offensive and defensive weapons.
• Operating systems—Systems that sit just above hardware to provide basic software services.
• Platforms—Systems that sit just above operating systems to provide advanced services.
• Scientific—Systems that are used for scientific research and applications.
• Tools—Systems that are used to develop other systems.
• Transportation—Systems that control water, ground, air, or space vehicles.
• Utilities—Systems that interact with other software to provide some point service
4.7 Architectural Styles:
* An architectural style is a transformation that is imposed on the design of an entire system.
* The software that is built for computer-based systems also exhibits one of many
architectural styles. Each style describes a system category that encompasses
# a set of components (e.g., a database, computational modules) that perform a function required by a system;
# a set of connectors that enable “communication, coordination and cooperation” among components;
# constraints that define how components can be integrated to form the system
# semantic models that enable a designer to understand the overall properties of a system by analyzing the known properties of its constituent parts
A Brief Taxonomy of Architectural Styles
 |
| Data-Centered Architecture |
 |
| Data-Flow Architecture |
 |
| Main Program / Sub-Program Architecture |
 |
| Layered Architecture |
Architectural Patterns
Architectural patterns address an application-specific problem within a specific context and under a set of limitations and constraints
Organization and Refinement
* Control: How is control managed within the architecture? hierarchy ? topology ? synchronized ?
* Data: How are data communicated between components?
4.8 Architectural Design:
Representing the System in Context
The generic structure of the architectural context diagram is illustrated in Figure below:
 |
| Architectural Context Diagram |
• Superordinate systems—those systems that use the target system as part of some higher-level processing scheme.
• Subordinate systems—those systems that are used by the target system and provide data or processing that are necessary to complete target system functionality.
• Peer-level systems—those systems that interact on a peer-to-peer basis (i.e., information is either produced or consumed by the peers and the target system.
• Actors—entities (people, devices) that interact with the target system by producing or consuming information that is necessary for requisite processing
The overall SafeHome product controller and the Internet-based system are both superordinate to the security function is shown below:
 |
| Architectural Context diagram of SafeHome security function |
Defining Archetypes
* An archetype is a class or pattern that represents a core abstraction that is critical to the design of an architecture for the target system
* SafeHome security function has the following archetypes:
• Node: Represents a cohesive collection of input and output elements of the home security function. For example a node might be comprised of (1) various sensors and (2) a variety of alarm (output) indicators.
• Detector: An abstraction that encompasses all sensing equipment that feeds information into the target system.
• Indicator: An abstraction that represents all mechanisms (e.g., alarm siren, flashing lights, bell) for indicating that an alarm condition is occurring.
• Controller: An abstraction that depicts the mechanism that allows the arming or disarming of a node. If controllers reside on a network, they have the ability to communicate with one another
Refining the Architecture into Components
The overall architectural structure (represented as a UML component diagram) is illustrated in Figure below:
• External communication management—coordinates communication of the security function with external entities such as other Internet-based systems and external alarm notification.
• Control panel processing—manages all control panel functionality.
• Detector management—coordinates access to all detectors attached to the system.
• Alarm processing—verifies and acts on all alarm conditions.
Describing Instantiations of the System
 |
| Components shown in above Figure are elaborated in this figure |
4.9 Assessing Alternative Architectural Designs
An Architecture Trade-Off Analysis Method (ATAM)
The design analysis activities that follow are performed iteratively:
1. Collect scenarios: A set of use cases is developed to represent the system from the user’s point of view.
2. Elicit requirements, constraints, and environment description: This information is determined as part of requirements engineering and is used to be certain that all stakeholder concerns have been addressed.
3. Describe the architectural styles/patterns that have been chosen to address the scenarios and requirements. The architectural style(s) should be described using one of the following architectural views:
• Module view for analysis of work assignments with components and the degree to which
information hiding has been achieved.
• Process view for analysis of system performance.
• Data flow view for analysis of the degree to which the architecture meets functional requirements.
4. Evaluate quality attributes by considering each attribute in isolation The number of quality attributes chosen for analysis is a function of the time available for review and the degree to which quality attributes are relevant to the system at hand. Quality attributes for architectural design assessment include reliability, performance, security, maintainability, flexibility, testability, portability, reusability, and interoperability.
5. Identify the sensitivity of quality attributes to various architectural attributes for a specific architectural style: This can be accomplished by making small changes in the architecture and determining how sensitive a quality attribute, say performance, is to the change. Any attributes that are significantly affected by variation in the architecture are termed sensitivity points.
6. Critique candidate architectures (developed in step 3) using the sensitivity analysis conducted in step 5: The SEI describes this approach in the following manner:
For example, the performance of a client-server architecture might be highly sensitive to the number of servers (performance increases, within some range, by increasing the number of servers). . . . The number of servers, then, is a trade-off point with respect to this architecture.
Architectural Complexity
Sharing dependencies represent dependence relationships among consumers who use the same resource or producers who produce for the same consumers. For example, for two components u and v, if u and v refer to the same global data, then there exists a shared
dependence relationship between u and v
Flow dependencies represent dependence relationships between producers and consumers of resources. For example, for two components u and v, if u must complete before control flows into v (prerequisite), or if u communicates with v by parameters, then there
exists a flow dependence relationship between u and v.
Constrained dependencies represent constraints on the relative flow of control among a set of activities. For example, for two components u and v, u and v cannot execute at the same time (mutual exclusion), then there exists a constrained dependence relationship between u and v.
Architectural Description Languages
Architectural description language (ADL) provides a semantics and syntax for describing a software architecture.
4.10 Architectural Mapping using Data Flow:
* Transform Mapping
Step 1. Review the fundamental system model
Step 2. Review and refine data flow diagrams for the software
Step 3. Determine whether the DFD has transform or transaction flow11 characteristics
Step 4. Isolate the transform center by specifying incoming and outgoing flow boundaries
Step 5. Perform “first-level factoring"
Step 6. Perform “second-level factoring"
Step 7. Refine the first-iteration architecture using design heuristics for improved software
quality
The objective of the preceding seven steps is to develop an architectural representation of software
 | |
|
* Refining the Architectural Design
Develop a representation of software that will meet all functional and performance requirements and merit acceptance based on design measures and heuristics
4.10 Components, 4.11 Designing Class-Based Components
* Large blocks of architecture are usually called Components.
*
4.12 Conducting Component-Level Design
4.13 Component-Level Design for Web Apps
4.14 Designing Traditional Components
4.15 Component-Based Development.
Quiz: Unit-4
Q1. Software design should always begin with a consideration of data
Q2. Refinement is actually a process of elaboration
Q3. Abstraction and refinement are complementary concepts.
Q4. Cohesion is an indication of the relative functional strength of a module
Q5. Coupling is an indication of the relative interdependence among modules
Assignment Unit-4
- Explain in detail Design Process.
- Demonstrate about Designing Class-Based Components
- Clearly explain about Architectural Mapping Using Data Flow
- Discuss in detail The Design Model
- Explain in detail Component-Level Design for WebApps
- Give a brief note on Design concepts
- Explain in detail Architectural Styles
- Explain in detail Component-Based Development.
- Explain how to Design Traditional Components.
Difficulty Levels: Level-I =Easy; Level-II= Moderate; Level-III=Difficult
Level-I=Q1,2,3; Level-II =Q4,5,6; Level-III = Q7,8,9;
----------------------
Other Questions to study:
Quiz Unit-4
1. A ___________ is a modular building block for computer software
(A) component (B) process (C) program (D) activity
2.A data abstraction is a named collection of data that describes a data object
(A) lesser (B) zero (C) higher (D) unpredictable
3. Software _________ alludes to “the overall structure of the software and the ways in which that structure provides conceptual integrity for a system.
(A) engineering (B) architecture (C) code (D) process
4. A ________ is a named nugget of insight which conveys the essence of a proven solution to a recurring problem within a certain context amidst competing concern.
(A) action (B) component (C) process (D) pattern
5. A ________ is a feature or behavior that is specified as part of the requirements model for the software
(A) drivers (B) concern (C) OS D) process.
6. __________ is the most common manifestation of separation of concerns
(A) concernity (B) Modularity (C) architecture (D) coding
7. __________ is a reorganization technique that simplifies the design (or code) of a component without changing its function or behavior
(A) refactoring (B) stories (C) process (D) coding
8. ______ implies a specific category within the overall software domain.
(A) Project (B) Plan (C) Genre (D) Coding
9. ________________ also called structured English or pseudocode, incorporates the logical structure of a programming language with the free-form expressive ability of a natural language (e.g., English)
(A) SEI (B) PDL (C) CMMI (D) ISO
10.__________ wrapping examines the internal processing details of the component and makes code-level modifications to remove any conflict.
(A) White-box (B) Blue box (C) Black-box (D) Gray-box
11.________ wrapping is applied when the component library provides a component extension language or API that enables conflicts to be removed or masked.
(A) White-box (B) Blue box (C) Black-box (D) Gray-box
12.________ wrapping requires the introduction of pre- and postprocessing at the component interface to remove or mask conflicts.
(A) White-box (B) Blue box (C) Black-box (D) Gray-box
KEY: 1-A, 2-C, 3-B, 4-D, 5-B, 6-B, 7-A, 8-C, 9-B, 10-A, 11-D, 12-C
Program design language (PDL)
Unit-5: UI Design, Software Quality Assurance, Testing (Strategies, Conventional Apps)
Topics:
5.1 The Golden Rules
5.2 User Interface Analysis and Design
5.3 Interface Analysis
5.4 Interface Design Steps
5.5 Web App Interface Design
5.6 Design Evaluation
5.7 Elements of Software Quality Assurance
5.8 SQA Tasks, Goals & Metrics
5.9 Statistical SQA,
5.10 Software Reliability
5.11 A Strategic Approach to Software Testing
5.12 Strategic Issues
5.13 Test Strategies for Conventional Software
5.14 Test Strategies for Object-Oriented Software
5.15 Test Strategies for Web Apps
5.16 Validation Testing
5.17 System Testing
5.18 The Art of Debugging
5.19 Software Testing Fundamentals
5.20 Internal and External Views of Testing
5.21 White-Box Testing
5.22 Basis Path Testing
5.1 The Golden Rules
1.
Place the user in control.
2.
Reduce the user’s memory load.
3.
Make the interface consistent.
|
Place the user
in control |
Reduce the
user’s memory load |
Make the
interface consistent |
|
Do not force unnecessary actions Flexible interaction Interaction must be interruptible Customization Skill levels from basic to advance Hide technical internals from casual
user Direct interaction of objects that
appear on screen |
Reduce demand on short-term memory meaningful defaults Define shortcuts for intuitive Visual interface to be on a real-world
effect Disclose information in a progressive
fashion. |
Current task into a meaningful context Maintain consistency across a family of
applications. Past interactive model met user
expectations? If yes, then do not modify unless compiled. |
5.2 User Interface Analysis and Design
|
Models |
Types of users |
Process |
|
Human engineer creates user model s/w engineer creates Design model End user develops mental image model Implementers of the system create the Implementation
model. |
Novice: No idea/ No knowledge of the
system Intermittent users: reasonable syntactic
knowledge, but low recall Good syntactic knowledge , shortcuts. |
Spiral model:  Focus on profile of users Define set of interface objects and
actions Prototype creating usage scenarios Interface Validation: User task implementation correctly Degree to which interface is easy to use
User’s acceptance level |
Assignment Unit-5
- Explain in detail User Interface Analysis and Design
- Demonstrate about Test Strategies for WebApps.
- Give a brief note on The Art of Debugging
- Discuss in detail Elements of Software Quality Assurance
- Explain in detail White-Box Testing, Basis Path Testing.
- Clearly explain about Validation Testing
- Explain in detail Test Strategies for Conventional Software.
- Explain in detail Software Testing Fundamentals
- Give a brief note on Software Quality Assurance Tasks.
Difficulty Levels: Level-I =Easy; Level-II= Moderate; Level-III=Difficult
Level-I=Q1,2,3; Level-II =Q4,5,6; Level-III = Q7,8,9;
----------------------
Other Questions to study:
Quiz Unit-5
1. These _________ actually form the basis for a set of user interface design principles that guide this important aspect of software design
(A) golden rules (B) agility (C) framework (D) task
2.A human engineer (or the software engineer) establishes a _______ model.
(A) implementation (B) component (C) user (D) unpredictable
3. When a number of different users, each playing different roles, makes use of a user interface, it is sometimes necessary to go beyond task analysis and object elaboration and apply ___________ analysis
(A) use cases (B) object elaboration (C) task elaboration (D) workflow
4. The use of navigation controls, menus, icons, and aesthetics (e.g., color, shape, layout) should be __________ throughout the WebApp
(A) bold or capital or italic (B) no protocol (C) different (D) consistent
5. The time to acquire a target is a function of the distance to and size of the target is called __________
(A) focus (B) Fitt's Law (C) flexibility D) efficiency
6. SQA = _________
(A) System Quantity Avoider (B) Software Quality Assurance (C) System Quality Assurance (D) Software Quality Analyzer
7. Core Steps of SixSigma are _____, ______, _______
(A) Define, Measure, Analyze (B) Design, Measure, Analyze (C) Design, Meetings, Analyze (D) Define, Measure, Apply
8. __________ refers to a different set of tasks that ensure that the software that has been built is traceable to customer requirements
(A) Verification (B) Validation (C) Variableness (D) Violation
9. _________ testing is actually a series of different tests whose primary purpose is to fully exercise the computer-based system
(A) Black Box (B) White Box (C) System (D) Unit
10. _________ occurs as a consequence of successful testing.
(A) Input (B) Debugging (C) Design (D) Architecture
KEY: 1-A, 2-C, 3-D, 4-D, 5-B, 6-B, 7-A, 8-B, 9-C, 10-B
Higher Education / Competitive Exam info
1. GATE info: This course is not included in GATE syllabus- Ref PDF
2. UGC NET info: This course is very very important for NET Exam aspirants.
Subject Code 87 --> Website for Syllabus and PDF Link
THANKYOU