SlideShare a Scribd company logo
1 of 69
Unit-5
Software Design
Design Concepts
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
• 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.
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
• Design Classes—provide design detail that will enable analysis classes to be
implemented
Data Abstraction
doordoor
implemented as a data structure
manufacturermanufacturer
model numbermodel number
typetype
swing directionswing direction
insertsinserts
lightslights
typetype
numbernumber
weightweight
opening mechanismopening mechanism
Procedural Abstraction
openopen
implemented with a "knowledge" of the
object that is associated with enter
details of enterdetails of enter
algorithmalgorithm
Modularity
• "modularity is the single attribute of software that
allows a program to be intellectually manageable”.
• 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.
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.
Classification of Cohesion
Classification of Cohesion
• Coincidental cohesion: A module is said to have
coincidental cohesion, if it performs a set of tasks
that relate to each other very loosely, if at all.
Classification of Cohesion
• Logical cohesion: A module is said to be logically
cohesive, if all elements of the module perform
similar operations, e.g. error handling, data input,
data output, etc.
Classification of Cohesion
• Temporal cohesion: When a module contains
functions that are related by the fact that all the
functions must be executed in the same time
span, the module is said to exhibit temporal
cohesion.
Classification of Cohesion
• Procedural cohesion: A module is said to possess
procedural cohesion, if the set of functions of the module
are all part of a procedure (algorithm) in which certain
sequence of steps have to be carried out for achieving an
objective, e.g. the algorithm for decoding a message.
• Communicational cohesion: A module is said to have
communicational cohesion, if all functions of the module
refer to or update the same data structure, e.g. the set of
functions defined on an array or a stack.
Classification of Cohesion
• Sequential cohesion: A module is said to possess
sequential cohesion, if the elements of a module form the
parts of sequence, where the output from one element of
the sequence is input to the next.
• Functional cohesion: Functional cohesion is said to exist, if
different elements of a module cooperate to achieve a
single function.
Classification of Coupling
Classification of Coupling
• Data coupling: Two modules are data coupled, if
they communicate through a parameter.
• Stamp coupling: Two modules are stamp coupled,
if they communicate using a composite data item
such as a record in PASCAL or a structure in C.
Classification of Coupling
• Control coupling: Control coupling exists between
two modules, if data from one module is used to
direct the order of instructions execution in
another.
• Common coupling: Two modules are common
coupled, if they share data through some global
data items.
• Content coupling: Content coupling exists between
two modules, if they share code, e.g. a branch
from one module into another module.
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.
• An aspect is a representation of a cross-
cutting concern.
Refactoring
"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 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
Architecture & User Interface
Design
Definitions
• The software architecture of a program or computing system is
the structure or structures of the system which comprise
– The software components
– The externally visible properties of those components
– The relationships among the components
• Software architectural design represents the structure of the
data and program components that are required to build a
computer-based system
• An architectural design model is transferable
– It can be applied to the design of other systems
– It represents a set of abstractions that enable software
engineers to describe architecture in predictable ways
Architectural Design Process
• Basic Steps
– Creation of the data design
– Derivation of one or more representations of the
architectural structure of the system
– Analysis of alternative architectural styles to choose the one
best suited to customer requirements and quality attributes
– Elaboration of the architecture based on the selected
architectural style
• A database designer creates the data architecture for a system
to represent the data components
• A system architect selects an appropriate architectural style
derived during system engineering and software requirements
analysis
Architectural Elements
• The architectural model is derived from
below 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.
Software Architecture
• “The software architecture of a program or computing system is
the structure or structures of the system, which comprise the
software components, the externally visible properties of those
components, and the relationships among them.”
• It is not operational software but it is representation that enables
software engineer to
– Analyze the effectiveness of design in meeting its stated
requirement.
– consider architectural alternatives at a stage when making
design changes is still relatively easy,
– reduce the risks associated with the construction of the
software.
Importance of Software Architecture
• Representations of software architecture are an enabler for
communication between all parties (stakeholders) interested in
the development
• Architecture highlights early design decisions that will have a
profound impact on all software engineering work that follows.
• Architecture “constitutes a relatively small, intellectually
graspable model of how the system is structured and how its
components work together”
Data Design
• The structure of data has always been an
important part of software design.
• Component level – the design of data structures
and the associated algorithms required to
manipulate them is essential to the creation of
high-quality applications.
• Application level – the translation of a data model
into a database design
Data design at the component level
• Component level focuses on the representation of data structures that are
directly accessed by one or more software components.
Principles are applicable to data design
1. The systematic analysis principles applied to function and behavior should
also be applied to data.
2. All data structures and the operations to be performed on each should be
identified.
3. A data dictionary should be established and used to define both data and
program design (operations)
4. Low-level data design decisions should be deferred until late in the design
process.
5. The representation of data structure should be known only to those
modules that must make direct use of the data contained within the
structure.
6. A library of useful data structures and the operations that may be
applied to them should be developed.
7. A software design and programming language should support the
specification and realization of abstract data types.
Architectural Style
• 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, co-ordinations and
cooperation” among components;
3. constraints that define how components can be integrated to form
the system
4. semantic models that enable a designer to understand the overall
properties of a system
It can be represent by
– Data-centered architecture
– Data flow architecture
– Call and return architecture
– Object oriented architecture
– Layered architecture.
Data-centered architecture
Data Flow architecture
Pipes and
filters
Batch Sequential
Data Flow architecture
• This architecture is applied when input data are to be transformed
through a series of computational or manipulative components into
output data.
• A pipe and filter pattern has a set of components, called filters,
connected by pipes that transmit data from one component to the
next.
• Each filter works independently (i.e. upstream, downstream) and is
designed to expect data input of a certain form, and produces data
output (to the next filter) of a specified form.
• the filter does not require knowledge of the working of its neighboring
filters.
• If the data flow degenerates into a single line of transforms, it is
termed batch sequential.
Call and return architecture
Call and return architecture
• Architecture style enables a software designer (system architect)
to achieve a program structure that is relatively easy to modify
and scale.
• Two sub-styles exist within this category:
1. Main/sub program architecture:
• Program structure decomposes function into a control hierarchy
where a “main” program invokes a number of program
components, which in turn may invoke still other components.
2. Remote procedure Call architecture:
• The components of a main program/subprogram architecture are
distributed across multiple computers on a network
Object-oriented architecture
Object-oriented architecture
• The object-oriented paradigm, like the abstract data type paradigm from
which it evolved, emphasizes the bundling of data and methods to
manipulate and access that data (Public Interface).
• Components of a system summarize data and the operations that must be
applied to manipulate the data.
• Communication and coordination between components is accomplished
via message passing.
Layered Architecture
User Interface
Analysis and Design
User Interface Design
• User interface design creates an effective
communication medium between a human
and a computer.
• Following a set of interface design principles,
design identifies interface objects and actions
and then creates a screen layout that forms
the basis for a user interface prototype.
Design Evaluation
user interface evaluation cycle
Background
• Interface design focuses on the following
– The design of interfaces between software components
– The design of interfaces between the software and other
nonhuman producers and consumers of information
– The design of the interface between a human and the
computer
• Graphical user interfaces (GUIs) have helped to eliminate
many of the most horrific interface problems
• However, some are still difficult to learn, hard to use,
confusing, counterintuitive, unforgiving, and frustrating
• User interface analysis and design has to do with the study of
people and how they relate to technology
A Spiral Process
• User interface development follows a spiral process
– Interface analysis (user, task, and environment analysis)
• Focuses on the profile of the users who will interact with the system
• Concentrates on users, tasks, content and work environment
– Interface design
• Defines a set of interface objects and actions (and their screen
representations) that enable a user to perform all defined tasks in a
manner that meets every usability goal defined for the system
– Interface construction
• Begins with a prototype that enables usage scenarios to be evaluated
• Continues with development tools to complete the construction
– Interface validation, focuses on
• The ability of the interface to implement every user task correctly, to
accommodate all task variations, and to achieve all general user
requirements
The Golden Rules of
User Interface Design
Place the User in Control
• Define interaction modes in a way that does not force a user into
unnecessary or undesired actions
– The user shall be able to enter and exit a mode with little or no
effort (e.g., spell check  edit text  spell check)
• Provide for flexible interaction
– The user shall be able to perform the same action via keyboard
commands, mouse movement, or voice recognition
• Allow user interaction to be interruptible and "undo"able
– The user shall be able to easily interrupt a sequence of actions
to do something else (without losing the work that has been
done so far)
– The user shall be able to "undo" any action
Place the User in Control
• Streamline interaction as skill levels advance and allow the interaction to be
customized
– The user shall be able to use a macro mechanism to perform a sequence of
repeated interactions and to customize the interface
• Hide technical internals from the casual user
– The user shall not be required to directly use operating system, file management
networking. etc., commands to perform any actions. Instead, these operations
shall be hidden from the user and performed "behind the scenes" in the form of
a real-world abstraction
• Design for direct interaction with objects that appear on the screen
– The user shall be able to manipulate objects on the screen in a manner similar to
what would occur if the object were a physical thing (e.g., stretch a rectangle,
press a button, move a slider)
Make the Interface Consistent
• The interface should present and acquire information in a
consistent fashion
• Allow the user to put the current task into a meaningful context
• Maintain consistency across a family of applications
• If past interactive models have created user expectations, do not
make changes unless there is a compelling reason to do so
• Four different models come into play when a user
interface is analyzed and designed
– User profile model – Established by a human engineer
or software engineer
– Design model – Created by a software engineer
– Implementation model – Created by the software
implementers
– User's mental model – Developed by the user when
interacting with the application
• The role of the interface designer is to merge these
differences and derive a consistent representation of the
interface
User Profile Model• Establishes the profile of the end-users of the system
– Based on age, gender, physical abilities, education, cultural or ethnic background,
motivation, goals, and personality
• Considers syntactic knowledge of the user
– The mechanics of interaction that are required to use the interface effectively
• Considers semantic knowledge of the user
– The underlying sense of the application; an understanding of the functions that are
performed, the meaning of input and output, and the objectives of the system
• Categorizes users as
– Novices
• No syntactic knowledge of the system, little semantic knowledge of the application, only
general computer usage
– Knowledgeable, intermittent users
• Reasonable semantic knowledge of the system, low recall of syntactic information to use the
interface
– Knowledgeable, frequent users
• Good semantic and syntactic knowledge (i.e., power user), look for shortcuts and abbreviated
modes of operation
Design Model
• Derived from the analysis model of the requirements
• Incorporates data, architectural, interface, and procedural
representations of the software
• Constrained by information in the requirements specification that
helps define the user of the system
• Normally is incidental to other parts of the design model
– But in many cases it is as important as the other parts
Implementation Model
• Consists of the look and feel of the interface
combined with all supporting information (books,
videos, help files) that describe system syntax and
semantics
• Strives to agree with the user's mental model; users
then feel comfortable with the software and use it
effectively
• Serves as a translation of the design model by
providing a realization of the information contained
in the user profile model and the user’s mental
model
User's Mental Model
• Often called the user's system perception
• Consists of the image of the system that users
carry in their heads
• Accuracy of the description depends upon the
user’s profile and overall familiarity with the
software in the application domain
User Interface Analysis
Elements of the User Interface
• To perform user interface analysis, the practitioner needs to
study and understand four elements
– The users who will interact with the system through the
interface
– The tasks that end users must perform to do their work
– The content that is presented as part of the interface
– The work environment in which these tasks will be
conducted
User Analysis
• The analyst strives to get the end user's mental model and the
design model to converge by understanding
– The users themselves
– How these people use the system
• Information can be obtained from
– User interviews with the end users
– Sales input from the sales people who interact with customers
and users on a regular basis
– Marketing input based on a market analysis to understand how
different population segments might use the software
– Support input from the support staff who are aware of what
works and what doesn't, what users like and dislike, what
features generate questions, and what features are easy to use
• A set of questions should be answered during user analysis
Task Analysis and Modeling
• Task analysis strives to know and understand
– The work the user performs in specific circumstances
– The tasks and subtasks that will be performed as the user does the work
– The specific problem domain objects that the user manipulates as work is
performed
– The sequence of work tasks (i.e., the workflow)
– The hierarchy of tasks
• Use cases
– Show how an end user performs some specific work-related task
– Enable the software engineer to extract tasks, objects, and overall workflow
of the interaction
– Helps the software engineer to identify additional helpful features
Content Analysis
• The display content may range from character-based reports,
to graphical displays, to multimedia information
• Display content may be
– Generated by components in other parts of the
application
– Acquired from data stored in a database that is accessible
from the application
– Transmitted from systems external to the application in
question
• The format and aesthetics of the content (as it is displayed by
the interface) needs to be considered
• A set of questions should be answered during content
Work Environment Analysis
• Software products need to be designed to fit into the work environment,
otherwise they may be difficult or frustrating to use
• Factors to consider include
– Type of lighting
– Display size and height
– Keyboard size, height and ease of use
– Mouse type and ease of use
– Surrounding noise
– Space limitations for computer and/or user
– Weather or other atmospheric conditions
– Temperature or pressure restrictions
– Time restrictions (when, how fast, and for how long)
Component-Level Design
Introduction
Background
• Component-level design occurs after the
first iteration of the architectural design
• It attempts to create a design model from
the analysis and architectural models
The Software Component
Defined
• A software component is a modular building block for computer
software
– It is a modular, deployable, and replaceable part of a system
that encapsulates implementation and exposes a set of
interfaces
• A component communicates and collaborates with
– Other components
– Entities outside the boundaries of the system
• Three different views of a component
– An object-oriented view
– A conventional view
– A process-related view
Designing Class-Based
Components
Component-Level Design
Guidelines• Components
– Establish naming conventions for components that are specified
as part of the architectural model and then refined and
elaborated as part of the component-level model
– Obtain architectural component names from the problem
domain and ensure that they have meaning to all stakeholders
who view the architectural model (e.g., Calculator)
– Use infrastructure component names that reflect their
implementation-specific meaning (e.g., Stack)
• Dependencies and inheritance in UML
– Model any dependencies from left to right and inheritance from
top (base class) to bottom (derived classes)
– Consider modeling any component dependencies as interfaces
rather than representing them as a direct component-to-
component dependency
Graphical Design Notation
Sequence If-then-else
Selection Repetition
T F
T
T
T
F
F
F
T
F
Tabular Design Notation
1) List all actions that can be associated with a specific procedure
(or module)
2) List all conditions (or decisions made) during execution of the
procedure
3) Associate specific sets of conditions with specific actions,
eliminating impossible combinations of conditions;
alternatively, develop every possible permutation of conditions
4) Define rules by indicating what action(s) occurs for a set of
conditions
Tabular Design Notation
(continued)
Conditions 1 2 3 4
Condition A T T F
Condition B F T
Condition C T T
Actions
Action X  
Action Y 
Action Z   
Rules

More Related Content

What's hot

Chapter 1 2 - some size factors
Chapter 1   2 - some size factorsChapter 1   2 - some size factors
Chapter 1 2 - some size factorsNancyBeaulah_R
 
Software Cost Estimation Techniques
Software Cost Estimation TechniquesSoftware Cost Estimation Techniques
Software Cost Estimation TechniquesSanthi thi
 
Modules and modularization criteria
Modules and modularization criteriaModules and modularization criteria
Modules and modularization criteriaUmaselvi_R
 
Design concept -Software Engineering
Design concept -Software EngineeringDesign concept -Software Engineering
Design concept -Software EngineeringVarsha Ajith
 
Software Cost Estimation in Software Engineering SE23
Software Cost Estimation in Software Engineering SE23Software Cost Estimation in Software Engineering SE23
Software Cost Estimation in Software Engineering SE23koolkampus
 
Designing Techniques in Software Engineering
Designing Techniques in Software EngineeringDesigning Techniques in Software Engineering
Designing Techniques in Software Engineeringkirupasuchi1996
 
Real time and distributed design
Real time and distributed designReal time and distributed design
Real time and distributed designpriyapavi96
 
Architecture design in software engineering
Architecture design in software engineeringArchitecture design in software engineering
Architecture design in software engineeringPreeti Mishra
 
component based development model
component based development modelcomponent based development model
component based development modelMuneeba Qamar
 
Phased life cycle model
Phased life cycle modelPhased life cycle model
Phased life cycle modelStephennancy
 
Pressman ch-11-component-level-design
Pressman ch-11-component-level-designPressman ch-11-component-level-design
Pressman ch-11-component-level-designOliver Cheng
 
10 software maintenance
10 software maintenance10 software maintenance
10 software maintenanceakiara
 
Incremental model
Incremental modelIncremental model
Incremental modelHpibmx
 
Defining the Problem - Goals and requirements
Defining the Problem - Goals and requirementsDefining the Problem - Goals and requirements
Defining the Problem - Goals and requirementsStephennancy
 

What's hot (20)

Chapter 1 2 - some size factors
Chapter 1   2 - some size factorsChapter 1   2 - some size factors
Chapter 1 2 - some size factors
 
Software Cost Estimation Techniques
Software Cost Estimation TechniquesSoftware Cost Estimation Techniques
Software Cost Estimation Techniques
 
Modules and modularization criteria
Modules and modularization criteriaModules and modularization criteria
Modules and modularization criteria
 
Design concept -Software Engineering
Design concept -Software EngineeringDesign concept -Software Engineering
Design concept -Software Engineering
 
Staffing level estimation
Staffing level estimation Staffing level estimation
Staffing level estimation
 
Software Cost Estimation in Software Engineering SE23
Software Cost Estimation in Software Engineering SE23Software Cost Estimation in Software Engineering SE23
Software Cost Estimation in Software Engineering SE23
 
Designing Techniques in Software Engineering
Designing Techniques in Software EngineeringDesigning Techniques in Software Engineering
Designing Techniques in Software Engineering
 
Software cost estimation
Software cost estimationSoftware cost estimation
Software cost estimation
 
Real time and distributed design
Real time and distributed designReal time and distributed design
Real time and distributed design
 
Architecture design in software engineering
Architecture design in software engineeringArchitecture design in software engineering
Architecture design in software engineering
 
Software requirements
Software requirementsSoftware requirements
Software requirements
 
Software design
Software designSoftware design
Software design
 
component based development model
component based development modelcomponent based development model
component based development model
 
unit 3 Design 1
unit 3 Design 1unit 3 Design 1
unit 3 Design 1
 
Phased life cycle model
Phased life cycle modelPhased life cycle model
Phased life cycle model
 
Pressman ch-11-component-level-design
Pressman ch-11-component-level-designPressman ch-11-component-level-design
Pressman ch-11-component-level-design
 
Software design
Software designSoftware design
Software design
 
10 software maintenance
10 software maintenance10 software maintenance
10 software maintenance
 
Incremental model
Incremental modelIncremental model
Incremental model
 
Defining the Problem - Goals and requirements
Defining the Problem - Goals and requirementsDefining the Problem - Goals and requirements
Defining the Problem - Goals and requirements
 

Viewers also liked

Agile Model Developement- Daniel Leroux
Agile Model Developement-  Daniel LerouxAgile Model Developement-  Daniel Leroux
Agile Model Developement- Daniel LerouxRoopa Nadkarni
 
Quality assurance and management, software engineering
Quality assurance and management, software engineeringQuality assurance and management, software engineering
Quality assurance and management, software engineeringRupesh Vaishnav
 
Software QA Fundamentals by Prabhath Darshana
Software QA Fundamentals by Prabhath DarshanaSoftware QA Fundamentals by Prabhath Darshana
Software QA Fundamentals by Prabhath DarshanaShamain Peiris
 
Modeling Requirements Using Examples
Modeling Requirements Using ExamplesModeling Requirements Using Examples
Modeling Requirements Using ExamplesExcella
 
Data Flow Diagram
Data Flow DiagramData Flow Diagram
Data Flow Diagramnethisip13
 
Software Quality Assurance
Software Quality AssuranceSoftware Quality Assurance
Software Quality AssuranceSachithra Gayan
 
Requirement Engineering
Requirement EngineeringRequirement Engineering
Requirement EngineeringSlideshare
 
Software quality
Software qualitySoftware quality
Software qualityjagadeesan
 
Software Architecture: Styles
Software Architecture: StylesSoftware Architecture: Styles
Software Architecture: StylesHenry Muccini
 
Software quality assurance
Software quality assuranceSoftware quality assurance
Software quality assuranceAman Adhikari
 
Software quality assurance lecture 1
Software quality assurance lecture 1Software quality assurance lecture 1
Software quality assurance lecture 1Abdul Basit
 
Introduction To Software Quality Assurance
Introduction To Software Quality AssuranceIntroduction To Software Quality Assurance
Introduction To Software Quality Assuranceruth_reategui
 
Dfd examples
Dfd examplesDfd examples
Dfd examplesMohit
 
requirements analysis and design
requirements analysis and designrequirements analysis and design
requirements analysis and designPreeti Mishra
 

Viewers also liked (17)

Agile Model Developement- Daniel Leroux
Agile Model Developement-  Daniel LerouxAgile Model Developement-  Daniel Leroux
Agile Model Developement- Daniel Leroux
 
Quality assurance and management, software engineering
Quality assurance and management, software engineeringQuality assurance and management, software engineering
Quality assurance and management, software engineering
 
Software QA Fundamentals by Prabhath Darshana
Software QA Fundamentals by Prabhath DarshanaSoftware QA Fundamentals by Prabhath Darshana
Software QA Fundamentals by Prabhath Darshana
 
Modeling Requirements Using Examples
Modeling Requirements Using ExamplesModeling Requirements Using Examples
Modeling Requirements Using Examples
 
Data Flow Diagram
Data Flow DiagramData Flow Diagram
Data Flow Diagram
 
Software Quality Assurance
Software Quality AssuranceSoftware Quality Assurance
Software Quality Assurance
 
Software Quality Assurance
Software Quality AssuranceSoftware Quality Assurance
Software Quality Assurance
 
Design engineering
Design engineeringDesign engineering
Design engineering
 
Requirement Engineering
Requirement EngineeringRequirement Engineering
Requirement Engineering
 
Software quality
Software qualitySoftware quality
Software quality
 
Quality Assurance in Software Ind.
Quality Assurance in Software Ind.Quality Assurance in Software Ind.
Quality Assurance in Software Ind.
 
Software Architecture: Styles
Software Architecture: StylesSoftware Architecture: Styles
Software Architecture: Styles
 
Software quality assurance
Software quality assuranceSoftware quality assurance
Software quality assurance
 
Software quality assurance lecture 1
Software quality assurance lecture 1Software quality assurance lecture 1
Software quality assurance lecture 1
 
Introduction To Software Quality Assurance
Introduction To Software Quality AssuranceIntroduction To Software Quality Assurance
Introduction To Software Quality Assurance
 
Dfd examples
Dfd examplesDfd examples
Dfd examples
 
requirements analysis and design
requirements analysis and designrequirements analysis and design
requirements analysis and design
 

Similar to Software design, software engineering

Unit 5 design engineering ssad
Unit 5 design engineering ssadUnit 5 design engineering ssad
Unit 5 design engineering ssadPreeti Mishra
 
Pressman_ch_9_design_engineering.ppt
Pressman_ch_9_design_engineering.pptPressman_ch_9_design_engineering.ppt
Pressman_ch_9_design_engineering.pptMotherTheresa2
 
Chapter 3_Software Design sunorganisedASE_BW_finalised.ppt
Chapter 3_Software Design sunorganisedASE_BW_finalised.pptChapter 3_Software Design sunorganisedASE_BW_finalised.ppt
Chapter 3_Software Design sunorganisedASE_BW_finalised.pptBule Hora University
 
UNIT-4design-concepts-se-pressman-ppt.PPT
UNIT-4design-concepts-se-pressman-ppt.PPTUNIT-4design-concepts-se-pressman-ppt.PPT
UNIT-4design-concepts-se-pressman-ppt.PPTmalathijanapati1
 
Software Eng S3 ( Software Design ).pptx
Software Eng S3 ( Software Design ).pptxSoftware Eng S3 ( Software Design ).pptx
Software Eng S3 ( Software Design ).pptxgauriVarshney8
 
Different approaches to software design
Different approaches to software designDifferent approaches to software design
Different approaches to software designSandeep Kumar Nayak
 
CS8494 SOFTWARE ENGINEERING Unit-3
CS8494 SOFTWARE ENGINEERING Unit-3CS8494 SOFTWARE ENGINEERING Unit-3
CS8494 SOFTWARE ENGINEERING Unit-3SIMONTHOMAS S
 
Design Concepts in Software Engineering-1.pptx
Design Concepts in Software Engineering-1.pptxDesign Concepts in Software Engineering-1.pptx
Design Concepts in Software Engineering-1.pptxKarthigaiSelviS3
 
Seii unit7 component-level-design
Seii unit7 component-level-designSeii unit7 component-level-design
Seii unit7 component-level-designAhmad sohail Kakar
 
A software design creates meaningful engineering representation
A software design creates meaningful engineering representationA software design creates meaningful engineering representation
A software design creates meaningful engineering representationRamandeep Singh
 

Similar to Software design, software engineering (20)

Software Design - SDLC Model
Software Design - SDLC ModelSoftware Design - SDLC Model
Software Design - SDLC Model
 
Unit 5 design engineering ssad
Unit 5 design engineering ssadUnit 5 design engineering ssad
Unit 5 design engineering ssad
 
Software design
Software designSoftware design
Software design
 
Pressman_ch_9_design_engineering.ppt
Pressman_ch_9_design_engineering.pptPressman_ch_9_design_engineering.ppt
Pressman_ch_9_design_engineering.ppt
 
Chapter 3_Software Design sunorganisedASE_BW_finalised.ppt
Chapter 3_Software Design sunorganisedASE_BW_finalised.pptChapter 3_Software Design sunorganisedASE_BW_finalised.ppt
Chapter 3_Software Design sunorganisedASE_BW_finalised.ppt
 
UNIT-4design-concepts-se-pressman-ppt.PPT
UNIT-4design-concepts-se-pressman-ppt.PPTUNIT-4design-concepts-se-pressman-ppt.PPT
UNIT-4design-concepts-se-pressman-ppt.PPT
 
Design engineering
Design engineeringDesign engineering
Design engineering
 
Software Eng S3 ( Software Design ).pptx
Software Eng S3 ( Software Design ).pptxSoftware Eng S3 ( Software Design ).pptx
Software Eng S3 ( Software Design ).pptx
 
Different approaches to software design
Different approaches to software designDifferent approaches to software design
Different approaches to software design
 
CS8494 SOFTWARE ENGINEERING Unit-3
CS8494 SOFTWARE ENGINEERING Unit-3CS8494 SOFTWARE ENGINEERING Unit-3
CS8494 SOFTWARE ENGINEERING Unit-3
 
Design Concepts in Software Engineering-1.pptx
Design Concepts in Software Engineering-1.pptxDesign Concepts in Software Engineering-1.pptx
Design Concepts in Software Engineering-1.pptx
 
Design engineering
Design engineeringDesign engineering
Design engineering
 
Chapter 6 design
Chapter 6 designChapter 6 design
Chapter 6 design
 
rEFUP.pdf
rEFUP.pdfrEFUP.pdf
rEFUP.pdf
 
Slides chapter 9
Slides chapter 9Slides chapter 9
Slides chapter 9
 
CHAPTER12.ppt
CHAPTER12.pptCHAPTER12.ppt
CHAPTER12.ppt
 
Seii unit7 component-level-design
Seii unit7 component-level-designSeii unit7 component-level-design
Seii unit7 component-level-design
 
design-concept.ppt
design-concept.pptdesign-concept.ppt
design-concept.ppt
 
A software design creates meaningful engineering representation
A software design creates meaningful engineering representationA software design creates meaningful engineering representation
A software design creates meaningful engineering representation
 
DESIGN CONCEPTS
DESIGN CONCEPTSDESIGN CONCEPTS
DESIGN CONCEPTS
 

More from Rupesh Vaishnav

Software maintenance and configuration management, software engineering
Software maintenance and  configuration management, software engineeringSoftware maintenance and  configuration management, software engineering
Software maintenance and configuration management, software engineeringRupesh Vaishnav
 
Software coding & testing, software engineering
Software coding & testing, software engineeringSoftware coding & testing, software engineering
Software coding & testing, software engineeringRupesh Vaishnav
 
Software as a service, software engineering
Software as a service, software engineeringSoftware as a service, software engineering
Software as a service, software engineeringRupesh Vaishnav
 
Requirement analysis and specification, software engineering
Requirement analysis and specification, software engineeringRequirement analysis and specification, software engineering
Requirement analysis and specification, software engineeringRupesh Vaishnav
 
Managing software project, software engineering
Managing software project, software engineeringManaging software project, software engineering
Managing software project, software engineeringRupesh Vaishnav
 
Intoduction to software engineering part 2
Intoduction to software engineering part 2Intoduction to software engineering part 2
Intoduction to software engineering part 2Rupesh Vaishnav
 
Intoduction to software engineering part 1
Intoduction to software engineering part 1Intoduction to software engineering part 1
Intoduction to software engineering part 1Rupesh Vaishnav
 
Agile development, software engineering
Agile development, software engineeringAgile development, software engineering
Agile development, software engineeringRupesh Vaishnav
 
Advanced topics in software engineering
Advanced topics in software engineeringAdvanced topics in software engineering
Advanced topics in software engineeringRupesh Vaishnav
 

More from Rupesh Vaishnav (9)

Software maintenance and configuration management, software engineering
Software maintenance and  configuration management, software engineeringSoftware maintenance and  configuration management, software engineering
Software maintenance and configuration management, software engineering
 
Software coding & testing, software engineering
Software coding & testing, software engineeringSoftware coding & testing, software engineering
Software coding & testing, software engineering
 
Software as a service, software engineering
Software as a service, software engineeringSoftware as a service, software engineering
Software as a service, software engineering
 
Requirement analysis and specification, software engineering
Requirement analysis and specification, software engineeringRequirement analysis and specification, software engineering
Requirement analysis and specification, software engineering
 
Managing software project, software engineering
Managing software project, software engineeringManaging software project, software engineering
Managing software project, software engineering
 
Intoduction to software engineering part 2
Intoduction to software engineering part 2Intoduction to software engineering part 2
Intoduction to software engineering part 2
 
Intoduction to software engineering part 1
Intoduction to software engineering part 1Intoduction to software engineering part 1
Intoduction to software engineering part 1
 
Agile development, software engineering
Agile development, software engineeringAgile development, software engineering
Agile development, software engineering
 
Advanced topics in software engineering
Advanced topics in software engineeringAdvanced topics in software engineering
Advanced topics in software engineering
 

Recently uploaded

Maher Othman Interior Design Portfolio..
Maher Othman Interior Design Portfolio..Maher Othman Interior Design Portfolio..
Maher Othman Interior Design Portfolio..MaherOthman7
 
CLOUD COMPUTING SERVICES - Cloud Reference Modal
CLOUD COMPUTING SERVICES - Cloud Reference ModalCLOUD COMPUTING SERVICES - Cloud Reference Modal
CLOUD COMPUTING SERVICES - Cloud Reference ModalSwarnaSLcse
 
Raashid final report on Embedded Systems
Raashid final report on Embedded SystemsRaashid final report on Embedded Systems
Raashid final report on Embedded SystemsRaashidFaiyazSheikh
 
Instruct Nirmaana 24-Smart and Lean Construction Through Technology.pdf
Instruct Nirmaana 24-Smart and Lean Construction Through Technology.pdfInstruct Nirmaana 24-Smart and Lean Construction Through Technology.pdf
Instruct Nirmaana 24-Smart and Lean Construction Through Technology.pdfEr.Sonali Nasikkar
 
Involute of a circle,Square, pentagon,HexagonInvolute_Engineering Drawing.pdf
Involute of a circle,Square, pentagon,HexagonInvolute_Engineering Drawing.pdfInvolute of a circle,Square, pentagon,HexagonInvolute_Engineering Drawing.pdf
Involute of a circle,Square, pentagon,HexagonInvolute_Engineering Drawing.pdfJNTUA
 
Tembisa Central Terminating Pills +27838792658 PHOMOLONG Top Abortion Pills F...
Tembisa Central Terminating Pills +27838792658 PHOMOLONG Top Abortion Pills F...Tembisa Central Terminating Pills +27838792658 PHOMOLONG Top Abortion Pills F...
Tembisa Central Terminating Pills +27838792658 PHOMOLONG Top Abortion Pills F...drjose256
 
Seismic Hazard Assessment Software in Python by Prof. Dr. Costas Sachpazis
Seismic Hazard Assessment Software in Python by Prof. Dr. Costas SachpazisSeismic Hazard Assessment Software in Python by Prof. Dr. Costas Sachpazis
Seismic Hazard Assessment Software in Python by Prof. Dr. Costas SachpazisDr.Costas Sachpazis
 
21P35A0312 Internship eccccccReport.docx
21P35A0312 Internship eccccccReport.docx21P35A0312 Internship eccccccReport.docx
21P35A0312 Internship eccccccReport.docxrahulmanepalli02
 
Artificial Intelligence in due diligence
Artificial Intelligence in due diligenceArtificial Intelligence in due diligence
Artificial Intelligence in due diligencemahaffeycheryld
 
5G and 6G refer to generations of mobile network technology, each representin...
5G and 6G refer to generations of mobile network technology, each representin...5G and 6G refer to generations of mobile network technology, each representin...
5G and 6G refer to generations of mobile network technology, each representin...archanaece3
 
analog-vs-digital-communication (concept of analog and digital).pptx
analog-vs-digital-communication (concept of analog and digital).pptxanalog-vs-digital-communication (concept of analog and digital).pptx
analog-vs-digital-communication (concept of analog and digital).pptxKarpagam Institute of Teechnology
 
Augmented Reality (AR) with Augin Software.pptx
Augmented Reality (AR) with Augin Software.pptxAugmented Reality (AR) with Augin Software.pptx
Augmented Reality (AR) with Augin Software.pptxMustafa Ahmed
 
Seizure stage detection of epileptic seizure using convolutional neural networks
Seizure stage detection of epileptic seizure using convolutional neural networksSeizure stage detection of epileptic seizure using convolutional neural networks
Seizure stage detection of epileptic seizure using convolutional neural networksIJECEIAES
 
Fuzzy logic method-based stress detector with blood pressure and body tempera...
Fuzzy logic method-based stress detector with blood pressure and body tempera...Fuzzy logic method-based stress detector with blood pressure and body tempera...
Fuzzy logic method-based stress detector with blood pressure and body tempera...IJECEIAES
 
Circuit Breakers for Engineering Students
Circuit Breakers for Engineering StudentsCircuit Breakers for Engineering Students
Circuit Breakers for Engineering Studentskannan348865
 
Adsorption (mass transfer operations 2) ppt
Adsorption (mass transfer operations 2) pptAdsorption (mass transfer operations 2) ppt
Adsorption (mass transfer operations 2) pptjigup7320
 
Worksharing and 3D Modeling with Revit.pptx
Worksharing and 3D Modeling with Revit.pptxWorksharing and 3D Modeling with Revit.pptx
Worksharing and 3D Modeling with Revit.pptxMustafa Ahmed
 
NEWLETTER FRANCE HELICES/ SDS SURFACE DRIVES - MAY 2024
NEWLETTER FRANCE HELICES/ SDS SURFACE DRIVES - MAY 2024NEWLETTER FRANCE HELICES/ SDS SURFACE DRIVES - MAY 2024
NEWLETTER FRANCE HELICES/ SDS SURFACE DRIVES - MAY 2024EMMANUELLEFRANCEHELI
 
Software Engineering Practical File Front Pages.pdf
Software Engineering Practical File Front Pages.pdfSoftware Engineering Practical File Front Pages.pdf
Software Engineering Practical File Front Pages.pdfssuser5c9d4b1
 
litvinenko_Henry_Intrusion_Hong-Kong_2024.pdf
litvinenko_Henry_Intrusion_Hong-Kong_2024.pdflitvinenko_Henry_Intrusion_Hong-Kong_2024.pdf
litvinenko_Henry_Intrusion_Hong-Kong_2024.pdfAlexander Litvinenko
 

Recently uploaded (20)

Maher Othman Interior Design Portfolio..
Maher Othman Interior Design Portfolio..Maher Othman Interior Design Portfolio..
Maher Othman Interior Design Portfolio..
 
CLOUD COMPUTING SERVICES - Cloud Reference Modal
CLOUD COMPUTING SERVICES - Cloud Reference ModalCLOUD COMPUTING SERVICES - Cloud Reference Modal
CLOUD COMPUTING SERVICES - Cloud Reference Modal
 
Raashid final report on Embedded Systems
Raashid final report on Embedded SystemsRaashid final report on Embedded Systems
Raashid final report on Embedded Systems
 
Instruct Nirmaana 24-Smart and Lean Construction Through Technology.pdf
Instruct Nirmaana 24-Smart and Lean Construction Through Technology.pdfInstruct Nirmaana 24-Smart and Lean Construction Through Technology.pdf
Instruct Nirmaana 24-Smart and Lean Construction Through Technology.pdf
 
Involute of a circle,Square, pentagon,HexagonInvolute_Engineering Drawing.pdf
Involute of a circle,Square, pentagon,HexagonInvolute_Engineering Drawing.pdfInvolute of a circle,Square, pentagon,HexagonInvolute_Engineering Drawing.pdf
Involute of a circle,Square, pentagon,HexagonInvolute_Engineering Drawing.pdf
 
Tembisa Central Terminating Pills +27838792658 PHOMOLONG Top Abortion Pills F...
Tembisa Central Terminating Pills +27838792658 PHOMOLONG Top Abortion Pills F...Tembisa Central Terminating Pills +27838792658 PHOMOLONG Top Abortion Pills F...
Tembisa Central Terminating Pills +27838792658 PHOMOLONG Top Abortion Pills F...
 
Seismic Hazard Assessment Software in Python by Prof. Dr. Costas Sachpazis
Seismic Hazard Assessment Software in Python by Prof. Dr. Costas SachpazisSeismic Hazard Assessment Software in Python by Prof. Dr. Costas Sachpazis
Seismic Hazard Assessment Software in Python by Prof. Dr. Costas Sachpazis
 
21P35A0312 Internship eccccccReport.docx
21P35A0312 Internship eccccccReport.docx21P35A0312 Internship eccccccReport.docx
21P35A0312 Internship eccccccReport.docx
 
Artificial Intelligence in due diligence
Artificial Intelligence in due diligenceArtificial Intelligence in due diligence
Artificial Intelligence in due diligence
 
5G and 6G refer to generations of mobile network technology, each representin...
5G and 6G refer to generations of mobile network technology, each representin...5G and 6G refer to generations of mobile network technology, each representin...
5G and 6G refer to generations of mobile network technology, each representin...
 
analog-vs-digital-communication (concept of analog and digital).pptx
analog-vs-digital-communication (concept of analog and digital).pptxanalog-vs-digital-communication (concept of analog and digital).pptx
analog-vs-digital-communication (concept of analog and digital).pptx
 
Augmented Reality (AR) with Augin Software.pptx
Augmented Reality (AR) with Augin Software.pptxAugmented Reality (AR) with Augin Software.pptx
Augmented Reality (AR) with Augin Software.pptx
 
Seizure stage detection of epileptic seizure using convolutional neural networks
Seizure stage detection of epileptic seizure using convolutional neural networksSeizure stage detection of epileptic seizure using convolutional neural networks
Seizure stage detection of epileptic seizure using convolutional neural networks
 
Fuzzy logic method-based stress detector with blood pressure and body tempera...
Fuzzy logic method-based stress detector with blood pressure and body tempera...Fuzzy logic method-based stress detector with blood pressure and body tempera...
Fuzzy logic method-based stress detector with blood pressure and body tempera...
 
Circuit Breakers for Engineering Students
Circuit Breakers for Engineering StudentsCircuit Breakers for Engineering Students
Circuit Breakers for Engineering Students
 
Adsorption (mass transfer operations 2) ppt
Adsorption (mass transfer operations 2) pptAdsorption (mass transfer operations 2) ppt
Adsorption (mass transfer operations 2) ppt
 
Worksharing and 3D Modeling with Revit.pptx
Worksharing and 3D Modeling with Revit.pptxWorksharing and 3D Modeling with Revit.pptx
Worksharing and 3D Modeling with Revit.pptx
 
NEWLETTER FRANCE HELICES/ SDS SURFACE DRIVES - MAY 2024
NEWLETTER FRANCE HELICES/ SDS SURFACE DRIVES - MAY 2024NEWLETTER FRANCE HELICES/ SDS SURFACE DRIVES - MAY 2024
NEWLETTER FRANCE HELICES/ SDS SURFACE DRIVES - MAY 2024
 
Software Engineering Practical File Front Pages.pdf
Software Engineering Practical File Front Pages.pdfSoftware Engineering Practical File Front Pages.pdf
Software Engineering Practical File Front Pages.pdf
 
litvinenko_Henry_Intrusion_Hong-Kong_2024.pdf
litvinenko_Henry_Intrusion_Hong-Kong_2024.pdflitvinenko_Henry_Intrusion_Hong-Kong_2024.pdf
litvinenko_Henry_Intrusion_Hong-Kong_2024.pdf
 

Software design, software engineering

  • 3. 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 • 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.
  • 4. 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 • Design Classes—provide design detail that will enable analysis classes to be implemented
  • 5. Data Abstraction doordoor implemented as a data structure manufacturermanufacturer model numbermodel number typetype swing directionswing direction insertsinserts lightslights typetype numbernumber weightweight opening mechanismopening mechanism
  • 6. Procedural Abstraction openopen implemented with a "knowledge" of the object that is associated with enter details of enterdetails of enter algorithmalgorithm
  • 7. Modularity • "modularity is the single attribute of software that allows a program to be intellectually manageable”. • 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.
  • 8. 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.
  • 10. Classification of Cohesion • Coincidental cohesion: A module is said to have coincidental cohesion, if it performs a set of tasks that relate to each other very loosely, if at all.
  • 11. Classification of Cohesion • Logical cohesion: A module is said to be logically cohesive, if all elements of the module perform similar operations, e.g. error handling, data input, data output, etc.
  • 12. Classification of Cohesion • Temporal cohesion: When a module contains functions that are related by the fact that all the functions must be executed in the same time span, the module is said to exhibit temporal cohesion.
  • 13. Classification of Cohesion • Procedural cohesion: A module is said to possess procedural cohesion, if the set of functions of the module are all part of a procedure (algorithm) in which certain sequence of steps have to be carried out for achieving an objective, e.g. the algorithm for decoding a message. • Communicational cohesion: A module is said to have communicational cohesion, if all functions of the module refer to or update the same data structure, e.g. the set of functions defined on an array or a stack.
  • 14. Classification of Cohesion • Sequential cohesion: A module is said to possess sequential cohesion, if the elements of a module form the parts of sequence, where the output from one element of the sequence is input to the next. • Functional cohesion: Functional cohesion is said to exist, if different elements of a module cooperate to achieve a single function.
  • 16. Classification of Coupling • Data coupling: Two modules are data coupled, if they communicate through a parameter. • Stamp coupling: Two modules are stamp coupled, if they communicate using a composite data item such as a record in PASCAL or a structure in C.
  • 17. Classification of Coupling • Control coupling: Control coupling exists between two modules, if data from one module is used to direct the order of instructions execution in another. • Common coupling: Two modules are common coupled, if they share data through some global data items. • Content coupling: Content coupling exists between two modules, if they share code, e.g. a branch from one module into another module.
  • 18. 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. • An aspect is a representation of a cross- cutting concern.
  • 19. Refactoring "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.
  • 20. 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
  • 21. 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
  • 22. Architecture & User Interface Design
  • 23. Definitions • The software architecture of a program or computing system is the structure or structures of the system which comprise – The software components – The externally visible properties of those components – The relationships among the components • Software architectural design represents the structure of the data and program components that are required to build a computer-based system • An architectural design model is transferable – It can be applied to the design of other systems – It represents a set of abstractions that enable software engineers to describe architecture in predictable ways
  • 24. Architectural Design Process • Basic Steps – Creation of the data design – Derivation of one or more representations of the architectural structure of the system – Analysis of alternative architectural styles to choose the one best suited to customer requirements and quality attributes – Elaboration of the architecture based on the selected architectural style • A database designer creates the data architecture for a system to represent the data components • A system architect selects an appropriate architectural style derived during system engineering and software requirements analysis
  • 25. Architectural Elements • The architectural model is derived from below 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.
  • 26. Software Architecture • “The software architecture of a program or computing system is the structure or structures of the system, which comprise the software components, the externally visible properties of those components, and the relationships among them.” • It is not operational software but it is representation that enables software engineer to – Analyze the effectiveness of design in meeting its stated requirement. – consider architectural alternatives at a stage when making design changes is still relatively easy, – reduce the risks associated with the construction of the software.
  • 27. Importance of Software Architecture • Representations of software architecture are an enabler for communication between all parties (stakeholders) interested in the development • Architecture highlights early design decisions that will have a profound impact on all software engineering work that follows. • Architecture “constitutes a relatively small, intellectually graspable model of how the system is structured and how its components work together”
  • 28. Data Design • The structure of data has always been an important part of software design. • Component level – the design of data structures and the associated algorithms required to manipulate them is essential to the creation of high-quality applications. • Application level – the translation of a data model into a database design
  • 29. Data design at the component level • Component level focuses on the representation of data structures that are directly accessed by one or more software components. Principles are applicable to data design 1. The systematic analysis principles applied to function and behavior should also be applied to data. 2. All data structures and the operations to be performed on each should be identified. 3. A data dictionary should be established and used to define both data and program design (operations) 4. Low-level data design decisions should be deferred until late in the design process.
  • 30. 5. The representation of data structure should be known only to those modules that must make direct use of the data contained within the structure. 6. A library of useful data structures and the operations that may be applied to them should be developed. 7. A software design and programming language should support the specification and realization of abstract data types.
  • 31. Architectural Style • 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, co-ordinations and cooperation” among components; 3. constraints that define how components can be integrated to form the system 4. semantic models that enable a designer to understand the overall properties of a system It can be represent by – Data-centered architecture – Data flow architecture – Call and return architecture – Object oriented architecture – Layered architecture.
  • 33. Data Flow architecture Pipes and filters Batch Sequential
  • 34. Data Flow architecture • This architecture is applied when input data are to be transformed through a series of computational or manipulative components into output data. • A pipe and filter pattern has a set of components, called filters, connected by pipes that transmit data from one component to the next. • Each filter works independently (i.e. upstream, downstream) and is designed to expect data input of a certain form, and produces data output (to the next filter) of a specified form. • the filter does not require knowledge of the working of its neighboring filters. • If the data flow degenerates into a single line of transforms, it is termed batch sequential.
  • 35. Call and return architecture
  • 36. Call and return architecture • Architecture style enables a software designer (system architect) to achieve a program structure that is relatively easy to modify and scale. • Two sub-styles exist within this category: 1. Main/sub program architecture: • Program structure decomposes function into a control hierarchy where a “main” program invokes a number of program components, which in turn may invoke still other components. 2. Remote procedure Call architecture: • The components of a main program/subprogram architecture are distributed across multiple computers on a network
  • 38. Object-oriented architecture • The object-oriented paradigm, like the abstract data type paradigm from which it evolved, emphasizes the bundling of data and methods to manipulate and access that data (Public Interface). • Components of a system summarize data and the operations that must be applied to manipulate the data. • Communication and coordination between components is accomplished via message passing.
  • 41. User Interface Design • User interface design creates an effective communication medium between a human and a computer. • Following a set of interface design principles, design identifies interface objects and actions and then creates a screen layout that forms the basis for a user interface prototype.
  • 43. Background • Interface design focuses on the following – The design of interfaces between software components – The design of interfaces between the software and other nonhuman producers and consumers of information – The design of the interface between a human and the computer • Graphical user interfaces (GUIs) have helped to eliminate many of the most horrific interface problems • However, some are still difficult to learn, hard to use, confusing, counterintuitive, unforgiving, and frustrating • User interface analysis and design has to do with the study of people and how they relate to technology
  • 44. A Spiral Process • User interface development follows a spiral process – Interface analysis (user, task, and environment analysis) • Focuses on the profile of the users who will interact with the system • Concentrates on users, tasks, content and work environment – Interface design • Defines a set of interface objects and actions (and their screen representations) that enable a user to perform all defined tasks in a manner that meets every usability goal defined for the system – Interface construction • Begins with a prototype that enables usage scenarios to be evaluated • Continues with development tools to complete the construction – Interface validation, focuses on • The ability of the interface to implement every user task correctly, to accommodate all task variations, and to achieve all general user requirements
  • 45. The Golden Rules of User Interface Design
  • 46. Place the User in Control • Define interaction modes in a way that does not force a user into unnecessary or undesired actions – The user shall be able to enter and exit a mode with little or no effort (e.g., spell check  edit text  spell check) • Provide for flexible interaction – The user shall be able to perform the same action via keyboard commands, mouse movement, or voice recognition • Allow user interaction to be interruptible and "undo"able – The user shall be able to easily interrupt a sequence of actions to do something else (without losing the work that has been done so far) – The user shall be able to "undo" any action
  • 47. Place the User in Control • Streamline interaction as skill levels advance and allow the interaction to be customized – The user shall be able to use a macro mechanism to perform a sequence of repeated interactions and to customize the interface • Hide technical internals from the casual user – The user shall not be required to directly use operating system, file management networking. etc., commands to perform any actions. Instead, these operations shall be hidden from the user and performed "behind the scenes" in the form of a real-world abstraction • Design for direct interaction with objects that appear on the screen – The user shall be able to manipulate objects on the screen in a manner similar to what would occur if the object were a physical thing (e.g., stretch a rectangle, press a button, move a slider)
  • 48. Make the Interface Consistent • The interface should present and acquire information in a consistent fashion • Allow the user to put the current task into a meaningful context • Maintain consistency across a family of applications • If past interactive models have created user expectations, do not make changes unless there is a compelling reason to do so
  • 49. • Four different models come into play when a user interface is analyzed and designed – User profile model – Established by a human engineer or software engineer – Design model – Created by a software engineer – Implementation model – Created by the software implementers – User's mental model – Developed by the user when interacting with the application • The role of the interface designer is to merge these differences and derive a consistent representation of the interface
  • 50. User Profile Model• Establishes the profile of the end-users of the system – Based on age, gender, physical abilities, education, cultural or ethnic background, motivation, goals, and personality • Considers syntactic knowledge of the user – The mechanics of interaction that are required to use the interface effectively • Considers semantic knowledge of the user – The underlying sense of the application; an understanding of the functions that are performed, the meaning of input and output, and the objectives of the system • Categorizes users as – Novices • No syntactic knowledge of the system, little semantic knowledge of the application, only general computer usage – Knowledgeable, intermittent users • Reasonable semantic knowledge of the system, low recall of syntactic information to use the interface – Knowledgeable, frequent users • Good semantic and syntactic knowledge (i.e., power user), look for shortcuts and abbreviated modes of operation
  • 51. Design Model • Derived from the analysis model of the requirements • Incorporates data, architectural, interface, and procedural representations of the software • Constrained by information in the requirements specification that helps define the user of the system • Normally is incidental to other parts of the design model – But in many cases it is as important as the other parts
  • 52. Implementation Model • Consists of the look and feel of the interface combined with all supporting information (books, videos, help files) that describe system syntax and semantics • Strives to agree with the user's mental model; users then feel comfortable with the software and use it effectively • Serves as a translation of the design model by providing a realization of the information contained in the user profile model and the user’s mental model
  • 53. User's Mental Model • Often called the user's system perception • Consists of the image of the system that users carry in their heads • Accuracy of the description depends upon the user’s profile and overall familiarity with the software in the application domain
  • 55. Elements of the User Interface • To perform user interface analysis, the practitioner needs to study and understand four elements – The users who will interact with the system through the interface – The tasks that end users must perform to do their work – The content that is presented as part of the interface – The work environment in which these tasks will be conducted
  • 56. User Analysis • The analyst strives to get the end user's mental model and the design model to converge by understanding – The users themselves – How these people use the system • Information can be obtained from – User interviews with the end users – Sales input from the sales people who interact with customers and users on a regular basis – Marketing input based on a market analysis to understand how different population segments might use the software – Support input from the support staff who are aware of what works and what doesn't, what users like and dislike, what features generate questions, and what features are easy to use • A set of questions should be answered during user analysis
  • 57. Task Analysis and Modeling • Task analysis strives to know and understand – The work the user performs in specific circumstances – The tasks and subtasks that will be performed as the user does the work – The specific problem domain objects that the user manipulates as work is performed – The sequence of work tasks (i.e., the workflow) – The hierarchy of tasks • Use cases – Show how an end user performs some specific work-related task – Enable the software engineer to extract tasks, objects, and overall workflow of the interaction – Helps the software engineer to identify additional helpful features
  • 58. Content Analysis • The display content may range from character-based reports, to graphical displays, to multimedia information • Display content may be – Generated by components in other parts of the application – Acquired from data stored in a database that is accessible from the application – Transmitted from systems external to the application in question • The format and aesthetics of the content (as it is displayed by the interface) needs to be considered • A set of questions should be answered during content
  • 59. Work Environment Analysis • Software products need to be designed to fit into the work environment, otherwise they may be difficult or frustrating to use • Factors to consider include – Type of lighting – Display size and height – Keyboard size, height and ease of use – Mouse type and ease of use – Surrounding noise – Space limitations for computer and/or user – Weather or other atmospheric conditions – Temperature or pressure restrictions – Time restrictions (when, how fast, and for how long)
  • 62. Background • Component-level design occurs after the first iteration of the architectural design • It attempts to create a design model from the analysis and architectural models
  • 64. Defined • A software component is a modular building block for computer software – It is a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces • A component communicates and collaborates with – Other components – Entities outside the boundaries of the system • Three different views of a component – An object-oriented view – A conventional view – A process-related view
  • 66. Component-Level Design Guidelines• Components – Establish naming conventions for components that are specified as part of the architectural model and then refined and elaborated as part of the component-level model – Obtain architectural component names from the problem domain and ensure that they have meaning to all stakeholders who view the architectural model (e.g., Calculator) – Use infrastructure component names that reflect their implementation-specific meaning (e.g., Stack) • Dependencies and inheritance in UML – Model any dependencies from left to right and inheritance from top (base class) to bottom (derived classes) – Consider modeling any component dependencies as interfaces rather than representing them as a direct component-to- component dependency
  • 67. Graphical Design Notation Sequence If-then-else Selection Repetition T F T T T F F F T F
  • 68. Tabular Design Notation 1) List all actions that can be associated with a specific procedure (or module) 2) List all conditions (or decisions made) during execution of the procedure 3) Associate specific sets of conditions with specific actions, eliminating impossible combinations of conditions; alternatively, develop every possible permutation of conditions 4) Define rules by indicating what action(s) occurs for a set of conditions
  • 69. Tabular Design Notation (continued) Conditions 1 2 3 4 Condition A T T F Condition B F T Condition C T T Actions Action X   Action Y  Action Z    Rules

Editor's Notes

  1. 3. A data dictionary explicitly represents the relationships among data objects and the constraints on the elements of a data structure. Algorithms that must take advantage of specific relationships can be more easily defined if a dictionary like data specification exists. 4. A process of stepwise refinement may be used for the design of data. That is, overall data organization may be defined during requirements analysis, refined during data design work, and specified in detail during component level design.
  2. 5. Information hiding and coupling provide important insight into the quality of software. 6. Data structures can be designed for reusability. A library of data structure templates (abstract data types) can reduce both specification and design effort for data.