Unit 2 Principles of Software Engineering; and Requirements Modeling

CHAPTER 4 Principle for guide Practice

CHAPTER 5 Understanding Requirements

CHAPTER 6 Requirements Modeling: Scenarios, Information, and Analysis Classes

CHAPTER 7 Requirements Modeling: Flow, Behavior, Patterns, and WebApp

CHAPTER 4 Principle for guide Practice

Q.1 gives the short note on Principle for guide Process

"Software engineering principles" —that does not have a three-year half-life. These software
engineering principles are likely to serve a professional programmer throughout his or her career.

Steve McConnell

Principles that Guide Process:-

 Principle #1. Be agile. Whether the process model you choose is prescriptive or agile,
the basic tenets of agile development should govern your approach.
 Principle #2. Focus on quality at every step. The exit condition for every process activity,
action, and task should focus on the quality of the work product that has been
produced.
 Principle #3. Be ready to adapt. Process is not a religious experience and dogma has no
place in it. When necessary, adapt your approach to constraints imposed by the
problem, the people, and the project itself.
  Principle #4. Build an effective team. Software engineering process and practice are
important, but the bottom line is people. Build a self-organizing team that has mutual
trust and respect.

 Principle #5. Establish mechanisms for communication and coordination. Projects fail
because important information falls into the cracks and/or stakeholders fail to
coordinate their efforts to create a successful end product.
 Principle #6. Manage change. The approach may be either formal or informal, but
mechanisms must be established to manage the way changes are requested, assessed,
approved and implemented.
 Principle #7. Assess risk. Lots of things can go wrong as software is being developed. It’s
essential that you establish contingency plans.
 Principle #8. Create work products that provide value for others. Create only those
work products that provide value for other process activities, actions or tasks

Q.2 gives the short note on Principle for guide Practice

Principles that Guide Practice:-

 Principle #1. Divide and conquer. Stated in a more technical manner, analysis and
design should always emphasize separation of concerns (SoC).
 Principle #2. Understand the use of abstraction. At it core, an abstraction is a
simplification of some complex element of a system used to communication meaning in
a single phrase.
 Principle #3. Strive for consistency. A familiar context makes software easier to use.
 Principle #4. Focus on the transfer of information. Pay special attention to the analysis,
design, construction, and testing of interfaces

 Principle #5. Build software that exhibits effective modularity. Separation of concerns
(Principle #1) establishes a philosophy for software. Modularity provides a mechanism
for realizing the philosophy.
 Principle #6. Look for patterns. Brad Appleton [App00] suggests that: “The goal of
patterns within the software community is to create a body of literature to help
software developers resolve recurring problems encountered throughout all of software
development.
 Principle #7. When possible, represent the problem and its solution from a number of
different perspectives.
 Principle #8. Remember that someone will maintain the software
Q.3 gives the short note on Principle for Communication

Communication Principles:-

 Principle #1. Listen. Try to focus on the speaker’s words, rather than formulating your
response to those words.
 Principle # 2. Prepare before you communicate. Spend the time to understand the
problem before you meet with others.
 Principle # 3. Someone should facilitate the activity. Every communication meeting
should have a leader (a facilitator) to keep the conversation moving in a productive
direction; (2) to mediate any conflict that does occur, and (3) to ensure than other
principles are followed.
 Principle #4. Face-to-face communication is best. But it usually works better when
some other representation of the relevant information is present

 Principle # 5. Take notes and document decisions. Someone participating in the

communication should serve as a “recorder” and write down all important points and
decisions.
 Principle # 6. Strive for collaboration. Collaboration and consensus occur when the
collective knowledge of members of the team is combined …
 Principle # 7. Stay focused, modularize your discussion. The more people involved in
any communication, the more likely that discussion will bounce from one topic to the
next.
 Principle # 8. If something is unclear, draw a picture.
 Principle # 9. (a) Once you agree to something, move on; (b) If you can’t agree to
something, move on; (c) If a feature or function is unclear and cannot be clarified at
the moment, move on.
 Principle # 10. Negotiation is not a contest or a game. It works best when both parties
win

Q.4 gives the short note on Principle for Planning

Planning Principles:-

 Principle #1. Understand the scope of the project. It’s impossible to use a roadmap if
you don’t know where you’re going. Scope provides the software team with a
destination.
 Principle #2. Involve the customer in the planning activity. The customer defines
priorities and establishes project constraints.
 Principle #3. Recognize that planning is iterative. A project plan is never engraved in
stone. As work begins, it very likely that things will change.
  Principle #4. Estimate based on what you know. The intent of estimation is to provide
an indication of effort, cost, and task duration, based on the team’s current
understanding of the work to be done

 Principle #5. Consider risk as you define the plan. If you have identified risks that
have high impact and high probability, contingency planning is necessary.
 Principle #6. Be realistic. People don’t work 100 percent of every day.
 Principle #7. Adjust granularity as you define the plan. Granularity refers to the level
of detail that is introduced as a project plan is developed.
 Principle #8. Define how you intend to ensure quality. The plan should identify how
the software team intends to ensure quality.
 Principle #9. Describe how you intend to accommodate change. Even the best
planning can be obviated by uncontrolled change.
 Principle #10. Track the plan frequently and make adjustments as required. Software
projects fall behind schedule one day at a time.

Q.5 gives the short note on Principle for Modeling

Modeling Principles:-

 In software engineering work, two classes of models can be created:

 Requirements models (also called analysis models) represent the customer
requirements by depicting the software in three different domains: the
information domain, the functional domain, and the behavioral domain.
Design models represent characteristics of the software that help practitioners to
construct it effectively: the architecture, the user interface, and component-level detail

 Principle #1. The information domain of a problem must be represented and

understood.
 Principle #2. The functions that the software performs must be defined.
 Principle #3. The behavior of the software (as a consequence of external events) must
be represented.
 Principle #4. The models that depict information, function, and behavior must be
partitioned in a manner that uncovers detail in a layered (or hierarchical) fashion.
 Principle #5. The analysis task should move from essential information toward
implementation detail

Q.6 gives the short note on Principle for Agile Modeling

Agile Modeling Principles:-

 Principle #1. The primary goal of the software team is to build software, not create
models.
 Principle #2. Travel light—don’t create more models than you need.
 Principle #3. Strive to produce the simplest model that will describe the problem or the
software.
 Principle #4. Build models in a way that makes them amenable to change.
 Principle #5. Be able to state an explicit purpose for each model that is created.
 Principle #6. Adapt the models you develop to the system at hand.
 Principle #7. Try to build useful models, but forget about building perfect models.
 Principle #8. Don’t become dogmatic about the syntax of the model. If it communicates
content successfully, representation is secondary.
 Principle #9. If your instincts tell you a model isn’t right even though it seems okay on
paper, you probably have reason to be concerned.
 Principle #10. Get feedback as soon as you can.

Q.7 gives the short note on Principle for constructing

Construction Principles:-

 The construction activity encompasses a set of coding and testing tasks that lead to
operational software that is ready for delivery to the customer or end-user.
 Coding principles and concepts are closely aligned programming style, programming
languages, and programming methods.
 Testing principles and concepts lead to the design of tests that systematically uncover
different classes of errors and to do so with a minimum amount of time and effort.

Q.8 gives the short note on Principle for Preparation Principles

 Before you write one line of code, be sure you:

• Understand of the problem you’re trying to solve.
• Understand basic design principles and concepts.
• Pick a programming language that meets the needs of the software to be built
and the environment in which it will operate.
• Select a programming environment that provides tools that will make your work
easier.
Create a set of unit tests that will be applied once the component you code is completed

Q.9 gives the short note on Principle for Coding Principles

 As you begin writing code, be sure you:
 • Constrain your algorithms by following structured programming [Boh00]
practice.
• Consider the use of pair programming
• Select data structures that will meet the needs of the design.
• Understand the software architecture and create interfaces that are consistent
with it.
• Keep conditional logic as simple as possible.
• Create nested loops in a way that makes them easily testable.
• Select meaningful variable names and follow other local coding standards.
• Write code that is self-documenting.
• Create a visual layout (e.g., indentation and blank lines) that aids understanding.
Q.10 gives the short note on Principle for Validation Principles

 After you’ve completed your first coding pass, be sure you:

• Conduct a code walkthrough when appropriate.
• Perform unit tests and correct errors you’ve uncovered.
• Refactor the code.

Q.11 gives the short note on Principle for Testing Principles

 Al Davis [Dav95] suggests the following:

 Principle #1. All tests should be traceable to customer requirements.
 Principle #2. Tests should be planned long before testing begins.
 Principle #3. The Pareto principle applies to software testing.
 Principle #4. Testing should begin “in the small” and progress toward testing “in the
large.”
 Principle #5. Exhaustive testing is not possible.

Q.12 gives the short note on Principle for Deployment Principles

 Principle #1. Customer expectations for the software must be managed.

Too often, the customer expects more than the team has promised to
deliver, and disappointment occurs immediately.
 Principle #2. A complete delivery package should be assembled and
tested.
 Principle #3. A support regime must be established before the software is
delivered. An end-user expects responsiveness and accurate information
when a question or problem arises.
  Principle #4. Appropriate instructional materials must be provided to end-
users.
 Principle #5. Buggy software should be fixed first, delivered later.

CHAPTER 5 Understanding Requirements

Q.1 what is Requirement Engineering? Explain Groundwork for Requirement

Requirement Engineering steps:-

 Inception—ask a set of questions that establish …
 basic understanding of the problem
 the people who want a solution
 the nature of the solution that is desired, and
 the effectiveness of preliminary communication and collaboration between the
customer and the developer
 Elicitation—elicit requirements from all stakeholders
 Elaboration—create an analysis model that identifies data, function and behavioral
requirements
 Negotiation—agree on a deliverable system that is realistic for developers and customers

 Specification—can be any one (or more) of the following:

 A written document
 A set of models
 A formal mathematical
 A collection of user scenarios (use-cases)
 A prototype
 Validation—a review mechanism that looks for
 errors in content or interpretation
 areas where clarification may be required
 missing information
 inconsistencies (a major problem when large products or systems are engineered)
 conflicting or unrealistic (unachievable) requirements.
 Requirements management

Steps for Groundwork for Requirement: =

 Identify stakeholders
 “Who else do you think I should talk to?”
  Recognize multiple points of view
 Work toward collaboration
 The first questions
 Who is behind the request for this work?
 Who will use the solution?
 What will be the economic benefit of a successful solution
 Is there another source for the solution that you need?

Q.2 what is Eliciting Requirements Explain with Activity Diagram in Detail

Eliciting Requirements:-

 meetings are conducted and attended by both software engineers and customers
 rules for preparation and participation are established
 an agenda is suggested
 a "facilitator" (can be a customer, a developer, or an outsider) controls the meeting
 a "definition mechanism" (can be work sheets, flip charts, or wall stickers or an
electronic bulletin board, chat room or virtual forum) is used
 the goal is
 to identify the problem
 propose elements of the solution
 negotiate different approaches, and
 specify a preliminary set of solution requirements

Q.3 Explain Building the Analysis Model

Building the Analysis Model:-

 Elements of the analysis model

 Scenario-based elements
• Functional—processing narratives for software functions
• Use-case—descriptions of the interaction between an “actor” and the
system
 Class-based elements
• Implied by scenarios
 Behavioral elements
• State diagram
 Flow-oriented elements
 • Data flow diagram

First Make Use case Diagram:-

 A collection of user scenarios that describe the thread of usage of a system

 Each scenario is described from the point-of-view of an “actor”—a person or device that
interacts with the software in some way
 Each scenario answers the following questions:
 Who is the primary actor, the secondary actor (s)?
 What are the actor’s goals?
 What preconditions should exist before the story begins?
 What main tasks or functions are performed by the actor?
 What extensions might be considered as the story is described?
 What variations in the actor’s interaction are possible?
 What system information will the actor acquire, produce, or change?
 Will the actor have to inform the system about changes in the external
environment?
 What information does the actor desire from the system?
 Does the actor wish to be informed about unexpected changes?
Second Make Class Diagram:-

From the SafeHome system

Sensor

name/id
type
location
area
characteristics

identify()
enable()
disable()
reconfigure ()

Third Make State Diagram:-

Fourth Make Data flow diagram:-

Q.4 Explain Negotiating Requirements

Negotiating Requirements are:-

 Identify the key stakeholders
 These are the people who will be involved in the negotiation
 Determine each of the stakeholders “win conditions”
 Win conditions are not always obvious
 Negotiate
Work toward a set of requirements that lead to “win-win

Q.5 Explain Validating Requirements

 Is each requirement consistent with the overall objective for the system/product?
 Have all requirements been specified at the proper level of abstraction? That is, do some
requirements provide a level of technical detail that is inappropriate at this stage?
 Is the requirement really necessary or does it represent an add-on feature that may not be
essential to the objective of the system?
 Is each requirement bounded and unambiguous?
 Does each requirement have attribution? That is, is a source (generally, a specific individual)
noted for each requirement?
 Do any requirements conflict with other requirements?
  Is each requirement achievable in the technical environment that will house the system
or product?
 Is each requirement testable, once implemented?
 Does the requirements model properly reflect the information, function and behavior of
the system to be built?
 Has the requirements model been “partitioned” in a way that exposes progressively
more detailed information about the system.
 Have requirements patterns been used to simplify the requirements model. Have all
patterns been properly validated? Are all patterns consistent with customer
requirements?

CHAPTER 6 Requirements Modeling: Scenarios, Information, and Analysis Classes

CHAPTER 7 Requirements Modeling: Flow, Behavior, Patterns, and WebApp

Q.1 Define Requirements modeling strategies

Requirements Modeling Strategies:-

 One view of requirements modeling, called structured analysis, considers data and the
processes that transform the data as separate entities.
 Data objects are modeled in a way that defines their attributes and relationships.
 Processes that manipulate data objects are modeled in a manner that shows
how they transform data as data objects flow through the system.
 A second approach to analysis modeled, called object-oriented analysis, focuses on
 the definition of classes and
The manner in which they collaborate with one another to effect customer requirements

Q.2 what is flow Oriented Modeling? Explain in details

Flow-Oriented Modeling:-

 Represents how data objects are transformed at they move through the system
 data flow diagram (DFD) is the diagrammatic form that is used
 Considered by many to be an “old school” approach, but continues to provide a view of
the system that is unique—it should be used to supplement other analysis model
elements

The Flow Model:-

Every computer-based system is an

Information transform ....

Flow Modeling Notation:-

External Entity:-
Process:-

Data Flow:-
Data Stores :-

Data Flow Diagramming: Guidelines :-

 all icons must be labeled with meaningful names

 the DFD evolves through a number of levels of detail
 always begin with a context level diagram (also called level 0)
 always show external entities at level 0
 always label data flow arrows
 do not represent procedural logic

Q.3 what is flow Behavior Modeling? Explain in details

Behavioral Modeling:-

 The behavioral model indicates how software will respond to external events or stimuli.
To create the model, the analyst must perform the following steps:
• Evaluate all use-cases to fully understand the sequence of interaction
within the system.
 • Identify events that drive the interaction sequence and understand how
these events relate to specific objects.
• Create a sequence for each use-case.
• Build a state diagram for the system.
• Review the behavioral model to verify accuracy and consistency.
First steps make use case diagram:-

Use-Cases:-

 a scenario that describes a “thread of usage” for a system

 actors represent roles people or devices play as the system functions
 users can play a number of different roles for a given scenario

Developing a Use-Case

 What are the main tasks or functions that are performed by the actor?
 What system information will the the actor acquire, produce or change?
 Will the actor have to inform the system about changes in the external environment?
 What information does the actor desire from the system?
 Does the actor wish to be informed about unexpected changes?
Second steps make sequence Diagram:-

Third make state diagram:-

The States of a System:-

 state—a set of observable circum-stances that characterizes the behavior of a system at

a given time
 state transition—the movement from one state to another
 event—an occurrence that causes the system to exhibit some predictable form of
behavior
 action—process that occurs as a consequence of making a transition

Q.4 write short note on Requirements Modeling for WebApps

Requirements Modeling for WebApps

Content Analysis. The full spectrum of content to be provided by the WebApp is identified,
including text, graphics and images, video, and audio data. Data modeling can be used to
identify and describe each of the data objects.
Interaction Analysis. The manner in which the user interacts with the WebApp is described in
detail. Use-cases can be developed to provide detailed descriptions of this interaction.
Functional Analysis. The usage scenarios (use-cases) created as part of interaction analysis
define the operations that will be applied to WebApp content and imply other processing
functions. All operations and functions are described in detail.
Configuration Analysis. The environment and infrastructure in which the WebApp resides are
described in detail.

Q.5 write short note on (1) data Tree (2) CRC Model (3) Responsibilities
Data Tree
Data Tree show hearty of components available in System

CRC Model:-

 Class-responsibility-collaborator (CRC) modeling [Wir90] provides a simple

means for identifying and organizing the classes that are relevant to system
or product requirements. Ambler [Amb95] describes CRC modeling in the
following way:
 A CRC model is really a collection of standard index cards that
represent classes. The cards are divided into three sections. Along
the top of the card you write the name of the class. In the body of
the card you list the class responsibilities on the left and the
collaborators on the right.

CRC Modeling:-
Responsibilities:-

Unit 3 Design Concepts; and Architectural Design

Chapter 8 Design Concepts

Chapter 9 Architectural Design

Chapter 8 Design Concepts

Q.1 defines Design Model? Explain Design Model in detail

 Mitch Kapor, the creator of Lotus 1-2-3, presented a “software design manifesto” in Dr. Dobbs
Journal. He said:
 Good software design should exhibit:
 Firmness: A program should not have any bugs that inhibit its function.
 Commodity: A program should be suitable for the purposes for which it was intended.
 Delight: The experience of using the program should be pleasurable one.
Design Model first step:-

Design and Quality:-

 the design must implement all of the explicit requirements contained in the analysis model, and
it must accommodate all of the implicit requirements desired by the customer.
 the design must be a readable, understandable guide for those who generate code and for those
who test and subsequently support the software.
the design should provide a complete picture of the software, addressing the data, functional, and
behavioral domains from an implementation perspective

Design Model Second Step:-

Quality Guidelines:

 A design should exhibit an architecture that (1) has been created using recognizable
architectural styles or patterns, (2) is composed of components that exhibit good design
characteristics and (3) can be implemented in an evolutionary fashion
 For smaller systems, design can sometimes be developed linearly.
 A design should be modular; that is, the software should be logically partitioned into elements
or subsystems
 A design should contain distinct representations of data, architecture, interfaces, and
components.
 A design should lead to data structures that are appropriate for the classes to be implemented
and are drawn from recognizable data patterns.
 A design should lead to components that exhibit independent functional characteristics.
 A design should lead to interfaces that reduce the complexity of connections between
components and with the external environment.
  A design should be derived using a repeatable method that is driven by information obtained
during software requirements analysis.
 A design should be represented using a notation that effectively communicates its meaning.

Design Model Third Step:-

Design Principles:

 The design process should not suffer from ‘tunnel vision.’

 The design should be traceable to the analysis model.
 The design should not reinvent the wheel.
 The design should “minimize the intellectual distance” [DAV95] between the software and the
problem as it exists in the real world.
 The design should exhibit uniformity and integration.
 The design should be structured to accommodate change.
 The design should be structured to degrade gently, even when aberrant data, events, or
operating conditions are encountered.
 Design is not coding, coding is not design.
 The design should be assessed for quality as it is being created, not after the fact.
 The design should be reviewed to minimize conceptual (semantic) errors.

Design Model Fourth Step:-

Fundamental Concepts:-

 Abstraction—data, procedure, control

 Architecture—the overall structure of the software
 Patterns—”conveys the essence” of a proven design solution
 Separation of concerns—any complex problem can be more easily handled if it is subdivided
into pieces
 Modularity—compartmentalization of data and function
 Hiding—controlled interfaces
 Functional independence—single-minded function and low coupling
 Refinement—elaboration of detail for all abstractions
 Aspects—a mechanism for understanding how global requirements affect design
 Refactoring—a reorganization technique that simplifies the design
 OO design concepts—Appendix II
 Design Classes—provide design detail that will enable analysis classes to be implemented
Data Abstraction:
Architecture
The overall structure of the software and the ways in which that structure provides conceptual
integrity for a system.” [SHA95a]

Structural properties. This aspect of the architectural design representation defines the components of
a system (e.g., modules, objects, filters) and the manner in which those components are packaged and
interact with one another. For example, objects are packaged to encapsulate both data and the
processing that manipulates the data and interact via the invocation of methods
Extra-functional properties. The architectural design description should address how the design
architecture achieves requirements for performance, capacity, reliability, security, adaptability, and
other system characteristics.
Families of related systems. The architectural design should draw upon repeatable patterns that are
commonly encountered in the design of families of similar systems. In essence, the design should have
the ability to reuse architectural building blocks.

Patterns:-

Design Pattern Template

Pattern name—describes the essence of the pattern in a short but expressive name
Intent—describes the pattern and what it does
Also-known-as—lists any synonyms for the pattern
Motivation—provides an example of the problem
Applicability—notes specific design situations in which the pattern is applicable
Structure—describes the classes that are required to implement the pattern
Participants—describes the responsibilities of the classes that are required to implement the pattern
Collaborations—describes how the participants collaborate to carry out their responsibilities
Consequences—describes the “design forces” that affect the pattern and the potential trade-offs that
must be considered when the pattern is implemented
Related patterns—cross-references related design patterns

Separation of Concerns:-

 Any complex problem can be more easily handled if it is subdivided into pieces that can each be
solved and/or optimized independently
 A concern is a feature or behavior that is specified as part of the requirements model for the
software
 By separating concerns into smaller, and therefore more manageable pieces, a problem takes
less effort and time to solve

Modularity:-

 "modularity is the single attribute of software that allows a program to be intellectually

manageable" [Mye78].
 Monolithic software (i.e., a large program composed of a single module) cannot be easily
grasped by a software engineer.
 The number of control paths, span of reference, number of variables, and overall
complexity would make understanding close to impossible.
  In almost all instances, you should break the design into many modules, hoping to make
understanding easier and as a consequence, reduce the cost required to build the software.

Information Hiding :-

Why Information Hiding?

 reduces the likelihood of “side effects”

 limits the global impact of local design decisions
 emphasizes communication through controlled interfaces
 discourages the use of global data
 leads to encapsulation—an attribute of high quality design
 results in higher quality software

Functional Independence :-
 Functional independence is achieved by developing modules with "single-minded" function and
an "aversion" to excessive interaction with other modules.
 Cohesion is an indication of the relative functional strength of a module.
 A cohesive module performs a single task, requiring little interaction with other
components in other parts of a program. Stated simply, a cohesive module should
(ideally) do just one thing.
 Coupling is an indication of the relative interdependence among modules.
  Coupling depends on the interface complexity between modules, the point at which
entry or reference is made to a module, and what data pass across the interface.

Stepwise Refinement:-

Aspects :-
 Consider two requirements, A and B. Requirement A crosscuts requirement B “if a software
decomposition [refinement] has been chosen in which B cannot be satisfied without taking A
into account. [Ros04]
 An aspect is a representation of a cross-cutting concern
Refactoring:-
 Fowler [FOW99] defines refactoring in the following manner:
 "Refactoring is the process of changing a software system in such a way that it does not
alter the external behavior of the code [design] yet improves its internal structure.”
 When software is refactored, the existing design is examined for
 redundancy
 unused design elements
 inefficient or unnecessary algorithms
 poorly constructed or inappropriate data structures
 or any other design failure that can be corrected to yield a better design.

OO Design Concepts:-

 Design classes
 Entity classes
 Boundary classes
 Controller classes
 Inheritance—all responsibilities of a superclass is immediately inherited by all subclasses
 Messages—stimulate some behavior to occur in the receiving object
 Polymorphism—a characteristic that greatly reduces the effort required to extend the design

Design Classes:-
 Analysis classes are refined during design to become entity classes
 Boundary classes are developed during design to create the interface (e.g., interactive screen or
printed reports) that the user sees and interacts with as the software is used.
 Boundary classes are designed with the responsibility of managing the way entity
objects are represented to users.
 Controller classes are designed to manage
 the creation or update of entity objects;
 the instantiation of boundary objects as they obtain information from entity objects;
 complex communication between sets of objects;
validation of data communicated between objects or between the user and the application

Design Model Fifth Step:-

Design Model Elements:-

 Data elements
 Data model --> data structures
 Data model --> database architecture
 Architectural elements
 Application domain
 Analysis classes, their relationships, collaborations and behaviors are transformed into
design realizations
 Patterns and “styles” (Chapters 9 and 12)
 Interface elements
 the user interface (UI)
  external interfaces to other systems, devices, networks or other producers or
consumers of information
 internal interfaces between various design components.
 Component elements
 Deployment elements

Architectural Elements:-

 The architectural model [Sha96] is derived from three sources:

 information about the application domain for the software to be built;
 specific requirements model elements such as data flow diagrams or analysis classes,
their relationships and collaborations for the problem at hand, and
 the availability of architectural patterns and styles

Interface Elements:-

Component Elements:-

SensorManagement
Sensor
Deployment Elements:-

Chapter 9 Architectural Design

Q.1 Why Architecture?

The architecture is not the operational software. Rather, it is a representation that enables a software
engineer to:
(1) analyze the effectiveness of the design in meeting its stated requirements,
(2) consider architectural alternatives at a stage when making design changes is still relatively easy, and
(3) reduce the risks associated with the construction of the software

Q.2 Why is Architecture Important?

 Representations of software architecture are an enabler for communication between all parties
(stakeholders) interested in the development of a computer-based system.
  The architecture highlights early design decisions that will have a profound impact on all
software engineering work that follows and, as important, on the ultimate success of the system
as an operational entity.
 Architecture “constitutes a relatively small, intellectually graspable mode of how the system is
structured and how its components work together” [BAS03].

Q.3 what is Architecture?

 The IEEE Computer Society has proposed IEEE-Std-1471-2000, Recommended Practice for
Architectural Description of Software-Intensive System, [IEE00]
 to establish a conceptual framework and vocabulary for use during the design of
software architecture,
 to provide detailed guidelines for representing an architectural description, and
 to encourage sound architectural design practices.
 The IEEE Standard defines an architectural description (AD) as a “a collection of products to
document an architecture.”
 The description itself is represented using multiple views, where each view is “a
representation of a whole system from the perspective of a related set of [stakeholder]
concerns.”

Q.4 what do you mean Architectural Genres

 Genre implies a specific category within the overall software domain.

 Within each category, you encounter a number of subcategories.
 For example, within the genre of buildings, you would encounter the following general
styles: houses, condos, apartment buildings, office buildings, industrial building,
warehouses, and so on.
 Within each general style, more specific styles might apply. Each style would have a
structure that can be described using a set of predictable patterns.

Q.5 what is Architecture? Explain Architectural Styles

Architecture is
 The description itself is represented using multiple views, where each view is “a
representation of a whole system from the perspective of a related set of [stakeholder]
concerns.”

Architectural Styles:-

Each style describes a system category that encompasses: (1) a set of components (e.g., a database,
computational modules) that perform a function required by a system, (2) a set of connectors that
enable “communication, coordination and cooperation” among components, (3) constraints that define
how components can be integrated to form the system, and (4) semantic models that enable a designer
to understand the overall properties of a system by analyzing the known properties of its constituent
parts.
 Data-centered architectures
 Data flow architectures
 Call and return architectures
 Object-oriented architectures
 Layered architectures
Q.6 give the short note on Architecture Design

Architectural Design:-

 The software must be placed into context

 the design should define the external entities (other systems, devices, people) that the
software interacts with and the nature of the interaction
 A set of architectural archetypes should be identified
 An archetype is an abstraction (similar to a class) that represents one element of system
behavior
  The designer specifies the structure of the system by defining and refining software components
that implement each archetype

Following Details for Architectural Design which is we have to design:-

First Architectural Context:

Safehome Internet-based
Product system

control
panel target system: surveillance
Security Function function
uses
homeowner peers
uses

uses

sensors sensors

Second Define Archetypes:-

 Cont roller

communicat es wit h

Node

Det ect or Indicat or

Figure 10.7 UML relat ionships f or Saf eHome securit y f unct ion archet ypes
(adapt ed f rom [ BOS00] )
Third Design Architectural Context:

Q.7 give the short note on (1) Architectural Complexity (2) ADL

Architectural Complexity:-
 the overall complexity of a proposed architecture is assessed by considering the dependencies
between components within the architecture [Zha98]
 Sharing dependencies represent dependence relationships among consumers who use
the same resource or producers who produce for the same consumers.
 Flow dependencies represent dependence relationships between producers and
consumers of resources.
 Constrained dependencies represent constraints on the relative flow of control among a
set of activities.
ADL:-

 Architectural description language (ADL) provides a semantics and syntax for describing a
software architecture
 Provide the designer with the ability to:
 decompose architectural components
 compose individual components into larger architectural blocks and
 represent interfaces (connection mechanisms) between components.

Q.8 how Architectural mapping using Data Flow

General Mapping Approach:-

 Isolate the transform center by specifying incoming and outgoing flow boundaries
 Perform "first-level factoring.”
 The program architecture derived using this mapping results in a top-down distribution
of control.
  Factoring leads to a program structure in which top-level components perform decision-
making and low-level components perform most input, computation, and output work.
 Middle-level components perform some control and do moderate amounts of work.
 Perform "second-level factoring."

Transform Mapping:-

b g h
a e f
d
c i
j
data flow model

x1 "Transform" mapping
x2 x3 x4

b c d e f g i

a h j

Factoring:-

direction of increasing
decision making typical "decision
making" modules

typical "worker" modules

First Level Factoring: