The document discusses various aspects of software design including the design process, concepts, models, heuristics, and styles. It describes software design as translating requirements into a finished product through iterative refinement. Key aspects covered include data/class design, architectural design, interface design, component design, abstraction, modularity, patterns, and information hiding. Architectural styles provide patterns for creating system architecture for given problems.
This Presentation contains all the topics in design concept of software engineering. This is much more helpful in designing new product. You have to consider some of the design concepts that are given in the ppt
Presentation covers all aspects about Software Designing that are followed by Software Engineering Industries. Readers can do detailed study about the Software Design Concepts like (Abstraction, Architecture, Patterns, Modularity, Information Hiding, Refinement, Functional Dependence, Cohesion, Coupling & Refactoring) plus Design Process.
Later then Design Principles are there to understand with Architectural Design, Architectural Styles, Data Centered Architecture, Data Flow Architecture, Call & Return Architecture, Object Oriented Architecture, Layered Architecture with other architectures are named at end of it.
Later then, Component Level Design is discussed. Then after UI Design & Rules of it, UI Design Models, Web Application Design, WebApp Interface Design are discussed at the end.
Comment back if you have any query about it.
The document discusses key aspects of the software design process including that design is iterative and represented at a high level of abstraction, guidelines for quality design include modularity, information hiding, and functional independence, and architectural design defines system context and archetypes that compose the system.
The document discusses software estimation and project planning. It covers estimating project cost and effort through decomposition techniques and empirical estimation models. Specifically, it discusses:
1) Decomposition techniques involve breaking down a project into functions and tasks to estimate individually, such as estimating lines of code or function points for each piece.
2) Empirical estimation models use historical data from past projects to generate estimates.
3) Key factors that affect estimation accuracy include properly estimating product size, translating size to effort/time/cost, and accounting for team abilities and requirements stability.
The document discusses the software design process. It begins by explaining that software design is an iterative process that translates requirements into a blueprint for constructing the software. It then describes the main steps and outputs of the design process, which include transforming specifications into design models, reviewing designs for quality, and producing a design document. The document also covers key concepts in software design like abstraction, architecture, patterns, modularity, and information hiding.
This document outlines the typical sections and contents of a software requirements specification (SRS). It discusses 12 common sections of an SRS, including an overview, development environments, external interfaces, functional requirements, performance requirements, exception handling, implementation priorities, foreseeable changes, acceptance criteria, design guidance, a cross-reference index, and a glossary. Key sections describe functional requirements using relational or state-oriented notation, performance characteristics like response times, and exception handling categories. The SRS should have properties like being correct, complete, consistent, unambiguous, functional, and verifiable.
The document discusses key concepts in software design, including:
- Design involves modeling the system architecture, interfaces, and components before implementation. This allows assessment and improvement of quality.
- Important design concepts span abstraction, architecture, patterns, separation of concerns, modularity, information hiding, and functional independence. Architecture defines overall structure and interactions. Patterns help solve common problems.
- Separation of concerns and related concepts like modularity and information hiding help decompose problems into independently designed and optimized pieces to improve manageability. Functional independence means each module has a single, well-defined purpose with minimal interaction.
UML (Unified Modeling Language) is a standard language for specifying, visualizing, constructing and documenting software systems. It uses mainly graphical notations to express design of software projects. There are two main categories of UML diagrams - structural diagrams which focus on static elements regardless of time, and behavioral diagrams which focus on dynamic features and business processes. Common UML diagram types include class, sequence, use case, activity, state machine, component, deployment and interaction diagrams.
This Presentation contains all the topics in design concept of software engineering. This is much more helpful in designing new product. You have to consider some of the design concepts that are given in the ppt
Presentation covers all aspects about Software Designing that are followed by Software Engineering Industries. Readers can do detailed study about the Software Design Concepts like (Abstraction, Architecture, Patterns, Modularity, Information Hiding, Refinement, Functional Dependence, Cohesion, Coupling & Refactoring) plus Design Process.
Later then Design Principles are there to understand with Architectural Design, Architectural Styles, Data Centered Architecture, Data Flow Architecture, Call & Return Architecture, Object Oriented Architecture, Layered Architecture with other architectures are named at end of it.
Later then, Component Level Design is discussed. Then after UI Design & Rules of it, UI Design Models, Web Application Design, WebApp Interface Design are discussed at the end.
Comment back if you have any query about it.
The document discusses key aspects of the software design process including that design is iterative and represented at a high level of abstraction, guidelines for quality design include modularity, information hiding, and functional independence, and architectural design defines system context and archetypes that compose the system.
The document discusses software estimation and project planning. It covers estimating project cost and effort through decomposition techniques and empirical estimation models. Specifically, it discusses:
1) Decomposition techniques involve breaking down a project into functions and tasks to estimate individually, such as estimating lines of code or function points for each piece.
2) Empirical estimation models use historical data from past projects to generate estimates.
3) Key factors that affect estimation accuracy include properly estimating product size, translating size to effort/time/cost, and accounting for team abilities and requirements stability.
The document discusses the software design process. It begins by explaining that software design is an iterative process that translates requirements into a blueprint for constructing the software. It then describes the main steps and outputs of the design process, which include transforming specifications into design models, reviewing designs for quality, and producing a design document. The document also covers key concepts in software design like abstraction, architecture, patterns, modularity, and information hiding.
This document outlines the typical sections and contents of a software requirements specification (SRS). It discusses 12 common sections of an SRS, including an overview, development environments, external interfaces, functional requirements, performance requirements, exception handling, implementation priorities, foreseeable changes, acceptance criteria, design guidance, a cross-reference index, and a glossary. Key sections describe functional requirements using relational or state-oriented notation, performance characteristics like response times, and exception handling categories. The SRS should have properties like being correct, complete, consistent, unambiguous, functional, and verifiable.
The document discusses key concepts in software design, including:
- Design involves modeling the system architecture, interfaces, and components before implementation. This allows assessment and improvement of quality.
- Important design concepts span abstraction, architecture, patterns, separation of concerns, modularity, information hiding, and functional independence. Architecture defines overall structure and interactions. Patterns help solve common problems.
- Separation of concerns and related concepts like modularity and information hiding help decompose problems into independently designed and optimized pieces to improve manageability. Functional independence means each module has a single, well-defined purpose with minimal interaction.
UML (Unified Modeling Language) is a standard language for specifying, visualizing, constructing and documenting software systems. It uses mainly graphical notations to express design of software projects. There are two main categories of UML diagrams - structural diagrams which focus on static elements regardless of time, and behavioral diagrams which focus on dynamic features and business processes. Common UML diagram types include class, sequence, use case, activity, state machine, component, deployment and interaction diagrams.
The document discusses key concepts in software design including:
- The main activities in software design are data design, architectural design, procedural design, and sometimes interface design. Preliminary design transforms requirements into architecture while detail design refines the architecture.
- Data design develops data structures to represent information from analysis. Architectural design defines program structure and interfaces. Procedural design represents structural components procedurally using notations like flowcharts.
- Other concepts discussed include modularity, abstraction, software architecture, control hierarchy, data structures, and information hiding. Modular design, abstraction and information hiding help manage complexity. Software architecture and control hierarchy define program organization.
Rumbaugh's Object Modeling Technique (OMT) is an object-oriented analysis and design methodology. It uses three main modeling approaches: object models, dynamic models, and functional models. The object model defines the structure of objects in the system through class diagrams. The dynamic model describes object behavior over time using state diagrams and event flow diagrams. The functional model represents system processes and data flow using data flow diagrams.
The document defines the software development life cycle (SDLC) and its phases. It discusses several SDLC models including waterfall, prototype, iterative enhancement, and spiral. The waterfall model follows sequential phases from requirements to maintenance with no overlap. The prototype model involves building prototypes for user feedback. The iterative enhancement model develops software incrementally. The spiral model is divided into risk analysis, engineering, construction, and evaluation cycles. The document also covers software requirements, elicitation through interviews and use cases, analysis through data, behavioral and functional modeling, and documentation in a software requirements specification.
Software design is an iterative process that translates requirements into a blueprint for constructing software. It involves understanding the problem from different perspectives, identifying solutions, and describing solution abstractions using notations. The design must satisfy users and developers by being correct, complete, understandable, and maintainable. During the design process, specifications are transformed into design models describing data structures, architecture, interfaces, and components, which are reviewed before development.
This document discusses software architecture from both a management and technical perspective. From a management perspective, it defines an architecture as the design concept, an architecture baseline as tangible artifacts that satisfy stakeholders, and an architecture description as a human-readable representation of the design. It also notes that mature processes, clear requirements, and a demonstrable architecture are important for predictable project planning. Technically, it describes Philippe Kruchten's model of software architecture, which includes use case, design, process, component, and deployment views that model different aspects of realizing a system's design.
Real Time Systems,Issues of real time system,Notations, state oriented Petrinets,Milestones, Walkthroughs, Inspections, Test plans,Functional test,Performance test,Stress test,Structural test
Architecture design in software engineeringPreeti Mishra
The document discusses software architectural design. It defines architecture as the structure of a system's components, their relationships, and properties. An architectural design model is transferable across different systems. The architecture enables analysis of design requirements and consideration of alternatives early in development. It represents the system in an intellectually graspable way. Common architectural styles structure systems and their components in different ways, such as data-centered, data flow, and call-and-return styles.
This document discusses different process models used in software development. It describes the key phases and characteristics of several common process models including waterfall, prototyping, V-model, incremental, iterative, spiral and agile development models. The waterfall model involves sequential phases from requirements to maintenance without iteration. Prototyping allows for user feedback earlier. The V-model adds verification and validation phases. Incremental and iterative models divide the work into smaller chunks to allow for iteration and user feedback throughout development.
UML deployment diagrams show the physical deployment of software components across hardware infrastructure. They depict the hardware elements like processors and devices, the software installed on each processor, and how the components connect. Deployment diagrams are created during system implementation to layout the physical architecture and are useful for embedded, client-server, and distributed systems to distinguish interfaces from data and host multiple software versions across servers.
This document discusses major factors that influence software cost estimation. It identifies programmer ability, product complexity, product size, available time, required reliability, and level of technology as key factors. It provides details on how each factor affects software cost, including equations to estimate programming time and effort based on variables like source lines of code and developer months. Program complexity is broken into three levels: application, utility, and system software. The document also discusses how underestimating code size and inability to compress development schedules can impact cost estimates.
This document discusses 15 factors that influence quality and productivity in software development processes: individual ability, team communication, product complexity, appropriate notations, systematic approaches, change control, level of technology, level of reliability, problem understanding, available time, required skills, facilities and resources, adequacy of training, management skills, and appropriate goals. Each factor is described in 1-3 paragraphs on how it can impact quality and productivity.
The document discusses component-level design which occurs after architectural design. It aims to create a design model from analysis and architectural models. Component-level design can be represented using graphical, tabular, or text-based notations. The key aspects covered include:
- Defining a software component as a modular building block with interfaces and collaboration
- Designing class-based components following principles like open-closed and dependency inversion
- Guidelines for high cohesion and low coupling in components
- Designing conventional components using notations like sequence, if-then-else, and tabular representations
The document discusses software engineering requirements analysis and specification. It covers topics like software requirements types (functional and non-functional), requirement engineering process, feasibility studies, requirements elicitation and analysis. The requirement engineering process involves activities like requirements discovery, analysis, specification, validation and management. It also discusses preparing a software requirements document that defines system specifications.
This document discusses criteria for modularization in software design. It defines modules as named entities that contain instructions, logic, and data structures. Good modularization aims to decompose a system into functional units with minimal coupling between modules. Modules should be designed for high cohesion (related elements) and low coupling (dependencies). The types of coupling from strongest to weakest are content, common, control, stamp, and data coupling. The document also discusses different types of cohesion within modules from weakest to strongest. The goal is functional cohesion with minimal coupling between modules.
The document discusses UML deployment diagrams which visualize the physical topology of a system where software artifacts are deployed. Deployment diagrams show nodes, which can be device or execution environment nodes, and artifacts deployed on the nodes. Communication paths represent connections between deployment targets that allow exchange of signals and messages. Deployments show the allocation of artifacts to deployment targets using dependencies labeled with "deploy". An example diagram depicts the deployment of a web application across load balanced servers.
This document discusses various design notations that can be used at different levels of software design, including:
- Data flow diagrams, structure charts, HIPO diagrams, pseudo code, and structured flowcharts, which can be used for external, architectural, and detailed design specifications.
- Data flow diagrams use nodes and arcs to represent processing activities and data flow. Structure charts show hierarchical structure and interconnections. HIPO diagrams use a tree structure.
- Other notations discussed include procedure templates for interface specifications, pseudo code for algorithms and logic, and decision tables for complex decision logic.
Unit 5- Architectural Design in software engineering arvind pandey
This document provides an overview of architectural design for software systems. It discusses topics like system organization, decomposition styles, and control styles. The key aspects covered are:
1. Architectural design identifies the subsystems, framework for control/communication, and is described in a software architecture.
2. Common decisions include system structure, distribution, styles, decomposition, and control strategy. Models are used to document the design.
3. Organization styles include repository (shared data), client-server (shared services), and layered (abstract machines). Decomposition can be through objects or pipelines. Control can be centralized or event-based.
Formal Specification in Software Engineering SE9koolkampus
This document discusses formal specification techniques for software. It describes algebraic techniques for specifying interfaces as abstract data types and model-based techniques for specifying system behavior. Algebraic specifications define operations and their relationships, while model-based specifications represent the system state using mathematical constructs like sets and sequences. Formal specification finds errors earlier and reduces rework, though it requires more upfront effort. The document also provides an example of formally specifying an air traffic control system and insulin pump.
The document discusses key design concepts in software engineering including abstraction, architecture, patterns, separation of concerns, modularity, information hiding, refinement, functional independence, aspects, refactoring, object-oriented design concepts, and design classes. It provides details on each concept, their importance in software design, and how they lead to the development of high-quality software.
The document discusses key concepts in design engineering for software. It covers principles like abstraction, refinement, modularity, architecture, and information hiding that are important for developing high quality software. It emphasizes that software design is an iterative process of translating requirements into lower levels of abstraction until implementation. The goals of design are to implement all requirements, provide an understandable guide for developers and testers, and give a complete picture of the software from an implementation perspective. Guidelines are provided for characteristics of good design like modularity, distinct representations, and deriving the design from requirements analysis.
This document discusses key concepts and principles of software design, including:
1) The software design process translates requirements into a design model through iterative refinement and aims to produce a quality design.
2) Important design concepts include abstraction, modularity, information hiding, and structural and functional partitioning.
3) Key principles for good design include traceability, minimizing intellectual distance, and accommodating change through structured modularity.
The document discusses key concepts in software design including:
- The main activities in software design are data design, architectural design, procedural design, and sometimes interface design. Preliminary design transforms requirements into architecture while detail design refines the architecture.
- Data design develops data structures to represent information from analysis. Architectural design defines program structure and interfaces. Procedural design represents structural components procedurally using notations like flowcharts.
- Other concepts discussed include modularity, abstraction, software architecture, control hierarchy, data structures, and information hiding. Modular design, abstraction and information hiding help manage complexity. Software architecture and control hierarchy define program organization.
Rumbaugh's Object Modeling Technique (OMT) is an object-oriented analysis and design methodology. It uses three main modeling approaches: object models, dynamic models, and functional models. The object model defines the structure of objects in the system through class diagrams. The dynamic model describes object behavior over time using state diagrams and event flow diagrams. The functional model represents system processes and data flow using data flow diagrams.
The document defines the software development life cycle (SDLC) and its phases. It discusses several SDLC models including waterfall, prototype, iterative enhancement, and spiral. The waterfall model follows sequential phases from requirements to maintenance with no overlap. The prototype model involves building prototypes for user feedback. The iterative enhancement model develops software incrementally. The spiral model is divided into risk analysis, engineering, construction, and evaluation cycles. The document also covers software requirements, elicitation through interviews and use cases, analysis through data, behavioral and functional modeling, and documentation in a software requirements specification.
Software design is an iterative process that translates requirements into a blueprint for constructing software. It involves understanding the problem from different perspectives, identifying solutions, and describing solution abstractions using notations. The design must satisfy users and developers by being correct, complete, understandable, and maintainable. During the design process, specifications are transformed into design models describing data structures, architecture, interfaces, and components, which are reviewed before development.
This document discusses software architecture from both a management and technical perspective. From a management perspective, it defines an architecture as the design concept, an architecture baseline as tangible artifacts that satisfy stakeholders, and an architecture description as a human-readable representation of the design. It also notes that mature processes, clear requirements, and a demonstrable architecture are important for predictable project planning. Technically, it describes Philippe Kruchten's model of software architecture, which includes use case, design, process, component, and deployment views that model different aspects of realizing a system's design.
Real Time Systems,Issues of real time system,Notations, state oriented Petrinets,Milestones, Walkthroughs, Inspections, Test plans,Functional test,Performance test,Stress test,Structural test
Architecture design in software engineeringPreeti Mishra
The document discusses software architectural design. It defines architecture as the structure of a system's components, their relationships, and properties. An architectural design model is transferable across different systems. The architecture enables analysis of design requirements and consideration of alternatives early in development. It represents the system in an intellectually graspable way. Common architectural styles structure systems and their components in different ways, such as data-centered, data flow, and call-and-return styles.
This document discusses different process models used in software development. It describes the key phases and characteristics of several common process models including waterfall, prototyping, V-model, incremental, iterative, spiral and agile development models. The waterfall model involves sequential phases from requirements to maintenance without iteration. Prototyping allows for user feedback earlier. The V-model adds verification and validation phases. Incremental and iterative models divide the work into smaller chunks to allow for iteration and user feedback throughout development.
UML deployment diagrams show the physical deployment of software components across hardware infrastructure. They depict the hardware elements like processors and devices, the software installed on each processor, and how the components connect. Deployment diagrams are created during system implementation to layout the physical architecture and are useful for embedded, client-server, and distributed systems to distinguish interfaces from data and host multiple software versions across servers.
This document discusses major factors that influence software cost estimation. It identifies programmer ability, product complexity, product size, available time, required reliability, and level of technology as key factors. It provides details on how each factor affects software cost, including equations to estimate programming time and effort based on variables like source lines of code and developer months. Program complexity is broken into three levels: application, utility, and system software. The document also discusses how underestimating code size and inability to compress development schedules can impact cost estimates.
This document discusses 15 factors that influence quality and productivity in software development processes: individual ability, team communication, product complexity, appropriate notations, systematic approaches, change control, level of technology, level of reliability, problem understanding, available time, required skills, facilities and resources, adequacy of training, management skills, and appropriate goals. Each factor is described in 1-3 paragraphs on how it can impact quality and productivity.
The document discusses component-level design which occurs after architectural design. It aims to create a design model from analysis and architectural models. Component-level design can be represented using graphical, tabular, or text-based notations. The key aspects covered include:
- Defining a software component as a modular building block with interfaces and collaboration
- Designing class-based components following principles like open-closed and dependency inversion
- Guidelines for high cohesion and low coupling in components
- Designing conventional components using notations like sequence, if-then-else, and tabular representations
The document discusses software engineering requirements analysis and specification. It covers topics like software requirements types (functional and non-functional), requirement engineering process, feasibility studies, requirements elicitation and analysis. The requirement engineering process involves activities like requirements discovery, analysis, specification, validation and management. It also discusses preparing a software requirements document that defines system specifications.
This document discusses criteria for modularization in software design. It defines modules as named entities that contain instructions, logic, and data structures. Good modularization aims to decompose a system into functional units with minimal coupling between modules. Modules should be designed for high cohesion (related elements) and low coupling (dependencies). The types of coupling from strongest to weakest are content, common, control, stamp, and data coupling. The document also discusses different types of cohesion within modules from weakest to strongest. The goal is functional cohesion with minimal coupling between modules.
The document discusses UML deployment diagrams which visualize the physical topology of a system where software artifacts are deployed. Deployment diagrams show nodes, which can be device or execution environment nodes, and artifacts deployed on the nodes. Communication paths represent connections between deployment targets that allow exchange of signals and messages. Deployments show the allocation of artifacts to deployment targets using dependencies labeled with "deploy". An example diagram depicts the deployment of a web application across load balanced servers.
This document discusses various design notations that can be used at different levels of software design, including:
- Data flow diagrams, structure charts, HIPO diagrams, pseudo code, and structured flowcharts, which can be used for external, architectural, and detailed design specifications.
- Data flow diagrams use nodes and arcs to represent processing activities and data flow. Structure charts show hierarchical structure and interconnections. HIPO diagrams use a tree structure.
- Other notations discussed include procedure templates for interface specifications, pseudo code for algorithms and logic, and decision tables for complex decision logic.
Unit 5- Architectural Design in software engineering arvind pandey
This document provides an overview of architectural design for software systems. It discusses topics like system organization, decomposition styles, and control styles. The key aspects covered are:
1. Architectural design identifies the subsystems, framework for control/communication, and is described in a software architecture.
2. Common decisions include system structure, distribution, styles, decomposition, and control strategy. Models are used to document the design.
3. Organization styles include repository (shared data), client-server (shared services), and layered (abstract machines). Decomposition can be through objects or pipelines. Control can be centralized or event-based.
Formal Specification in Software Engineering SE9koolkampus
This document discusses formal specification techniques for software. It describes algebraic techniques for specifying interfaces as abstract data types and model-based techniques for specifying system behavior. Algebraic specifications define operations and their relationships, while model-based specifications represent the system state using mathematical constructs like sets and sequences. Formal specification finds errors earlier and reduces rework, though it requires more upfront effort. The document also provides an example of formally specifying an air traffic control system and insulin pump.
The document discusses key design concepts in software engineering including abstraction, architecture, patterns, separation of concerns, modularity, information hiding, refinement, functional independence, aspects, refactoring, object-oriented design concepts, and design classes. It provides details on each concept, their importance in software design, and how they lead to the development of high-quality software.
The document discusses key concepts in design engineering for software. It covers principles like abstraction, refinement, modularity, architecture, and information hiding that are important for developing high quality software. It emphasizes that software design is an iterative process of translating requirements into lower levels of abstraction until implementation. The goals of design are to implement all requirements, provide an understandable guide for developers and testers, and give a complete picture of the software from an implementation perspective. Guidelines are provided for characteristics of good design like modularity, distinct representations, and deriving the design from requirements analysis.
This document discusses key concepts and principles of software design, including:
1) The software design process translates requirements into a design model through iterative refinement and aims to produce a quality design.
2) Important design concepts include abstraction, modularity, information hiding, and structural and functional partitioning.
3) Key principles for good design include traceability, minimizing intellectual distance, and accommodating change through structured modularity.
This document discusses key concepts and principles of software design. It explains that software design transforms analysis models into a design model through activities like architectural design, interface design, data design, and component-level design. Some key design concepts discussed include abstraction, refinement, modularity, architecture, procedures, and information hiding. The document also covers principles of effective modular design such as high cohesion and low coupling between modules. Different types of cohesion and coupling are defined. Overall, the document provides an overview of the software design process and some fundamental concepts involved.
The document discusses key concepts in software design including abstraction, architecture, patterns, modularity, coupling and cohesion, and information hiding. It defines software design as transforming user requirements into an implementable form using programming languages. The software design process exists between requirements and programming and yields architectural, high-level, and detailed designs. It also outlines characteristics of good design like correctness, efficiency, and understandability.
Software design is the process of envisioning and defining software solutions to one or more sets of problems. One of the main components of software design is the software requirements analysis (SRA).
The document discusses key concepts in software design including abstraction, modularity, information hiding, functional independence, and refactoring. It also covers design patterns, architectural patterns, data abstraction, procedural abstraction, architecture, and principles of good modular design.
This document discusses various topics related to software design including design principles, concepts, modeling, and architecture. It provides examples of class/data design, architectural design, interface design, and component design. Some key points discussed include:
- Software design creates representations and models that provide details on architecture, data structures, interfaces, and components needed to implement the system.
- Design concepts like abstraction, modularity, encapsulation, and information hiding are important to reduce complexity and improve design.
- Different types of design models include data/class design, architectural design, interface design, and component-level design.
- Good software architecture and design lead to systems that are more understandable, maintainable, and of higher quality.
The document discusses key concepts and principles of software design. It begins by defining design as a blueprint for solving problems specified in requirements. Good design implements all requirements, provides a readable guide, and gives a complete picture of the software. The design process has two levels - top-level design of modules and interfaces and detailed design of module internals. The document then covers fundamental design concepts like abstraction, refinement, modularity, architecture, partitioning, data structures, procedures, information hiding, and functional independence. It provides examples and guidelines for applying these concepts to create a high-quality design.
The document discusses key concepts in software design including:
1) Design creates representations of software architecture, data structures, interfaces and components that provide details for implementation beyond what is in requirements.
2) Design allows modeling of a system before implementation to assess quality.
3) Good design should exhibit firmness, commodity, and delight according to a "software design manifesto."
The document discusses various aspects of design modeling for software engineering projects. It describes how the design model builds upon the analysis model by refining and adding more implementation details to elements like data design, architectural design, interface design, and component design. It also covers important design concepts like abstraction, architecture, patterns, modularity, information hiding, and functional independence. Quality guidelines for software design are provided along with principles of object-oriented design.
The document discusses key concepts in design modeling for software engineering projects, including:
- Data/class design transforms analysis models into design class structures and data structures.
- Architectural design defines relationships between major software elements and how they interact.
- Interface, component, and other designs further refine elements from analysis into implementation-specific details.
- Design principles include traceability to analysis, avoiding reinventing solutions, and structuring for change and graceful degradation.
This document discusses fundamentals of software engineering design. It explains that design creates a representation of software that provides implementation details beyond an analysis model. Four design models are described: data design, architectural design, user interface design, and component-level design. Design principles, concepts like abstraction and patterns are explained. Tools like CASE tools can support design, and evaluation ensures a quality design. A design specification document formally specifies the design.
Function Oriented and Object Oriented Design,Modularization techniquesnimmik4u
Design activity & its objectives – Function Oriented and Object Oriented Design- Modularization techniques - module structure and its representation, interface and information hiding, categories, specific techniques to accommodate change, stepwise refinement, top-down and bottom-up design - Handling anomalies.
The document discusses key concepts in software design including abstraction, architecture, patterns, modularity, information hiding, and functional independence. It explains that software design is an iterative process that transforms requirements into a blueprint for constructing the software through design models, data structures, system architecture, interfaces, and components. Good software design exhibits qualities like being bug-free, suitable for its intended purpose, and a pleasurable user experience.
A software design creates meaningful engineering representationRamandeep Singh
A software design creates a model of the software product that will be built. Designers must consider alternative designs and choose elements that best match requirements. The design model can be traced to customer requirements and assessed for quality. During design, software requirements are transformed into detailed design models describing data structures, architecture, interfaces, and components needed to implement the system. Each design is reviewed for quality before moving to the next development phase.
This document discusses key concepts in software design engineering including analysis models, design models, the programmer's approach versus best practices, purposes of design, quality guidelines, design principles, fundamental concepts like abstraction and architecture, and specific design concepts like patterns, modularity, and information hiding. It emphasizes that design is important for translating requirements into a quality software solution before implementation begins.
The design model transforms requirements from the analysis model into a blueprint for constructing the software. It includes four main elements: the data/class design, architectural design, interface design, and component-level design. These elements are developed iteratively through increasing levels of abstraction, starting with high-level elements that are traced to requirements and refining into lower-level representations. The design model aims to implement requirements while considering quality guidelines around modularity, patterns, and other design concepts.
Lecture # 8 software design and architecture (SDA).pptesrabilgic2
This document provides an overview of software design and architecture. It discusses major areas of concern like data, architecture, interface, and component design. Good design is the foundation for quality software and should implement requirements, be readable, and provide a complete implementation picture. General guidelines include using design patterns and logically partitioning components. Key principles are avoiding tunnel vision and reviewing design. The design process transforms analysis models into data structures, program structure, interfaces, and procedural details through techniques like abstraction, modularity, hierarchy, and information hiding.
1. The document discusses key concepts in software design including transforming customer requirements into an implementable form, designing modules, control relationships, interfaces, data structures, and algorithms.
2. It also covers preliminary and detailed design phases, where preliminary design identifies modules and relationships, and detailed design specifies data structures and algorithms.
3. Design principles like abstraction, refinement, modularity, architecture, control hierarchy, and information hiding are explained as important concepts for creating a complete design model.
Similar to CS8494 SOFTWARE ENGINEERING Unit-3 (20)
Cs8092 computer graphics and multimedia unit 5SIMONTHOMAS S
This document discusses multimedia authoring tools and techniques. It covers several topics:
1. Types of multimedia authoring tools including card/page based tools, icon based tools, and time based tools. Popular examples are discussed.
2. Key features and capabilities of authoring tools including editing, programming, interactivity, playback, delivery, and project organization.
3. Authoring system metaphors like hierarchical, flow control, and different technologies focused on like hypermedia.
4. Considerations for multimedia production, presentation, and automatic authoring. Professional development tools are also outlined.
Cs8092 computer graphics and multimedia unit 4SIMONTHOMAS S
This document provides an overview of multimedia system design and multimedia file handling. It discusses multimedia basics and system architecture. Key topics covered include defining objects for multimedia systems, multimedia data interface standards, compression and decompression, data and file format standards, and multimedia I/O technologies. It also examines digital voice and audio, video, image and animation, and full motion video. Storage and retrieval technologies are also mentioned.
Cs8092 computer graphics and multimedia unit 3SIMONTHOMAS S
The document discusses various methods for representing 3D objects in computer graphics, including polygon meshes, curved surfaces defined by equations or splines, and sweep representations. It also covers 3D transformations like translation, rotation, and scaling. Key representation methods discussed are polygonal meshes, NURBS curves and surfaces, and extruded and revolved shapes. Transformation operations covered are translation using addition of a offset vector, and rotation using a rotation matrix.
Cs8092 computer graphics and multimedia unit 2SIMONTHOMAS S
This document discusses two-dimensional graphics transformations and matrix representations. It covers topics such as translation, rotation, scaling, reflections, shearing, and representing composite transformations using matrix multiplication. Homogeneous coordinates are also introduced as a way to represent 2D points using 3-dimensional vectors and matrices for transformations.
Cs8092 computer graphics and multimedia unit 1SIMONTHOMAS S
This document discusses illumination models and color models in computer graphics. It begins by introducing illumination models which determine the perceived color and intensity at points on a surface given lighting conditions. It then covers various lighting models including point light sources, damping of light intensity over distance, and the Phong illumination model for specular reflection. It also discusses surface illumination factors like reflection, transmission and absorption of light. Basic illumination models are presented combining ambient, diffuse and specular reflection. The document concludes by covering rendering of polygons using constant, Gouraud and Phong shading to interpolate colors across surfaces.
Take minutes, post minutes, track action items
Responsible for inter-group communication
Liaison with other teams
Coordinate interfaces
Responsible for quality of work products
Enforce standards and guidelines
Review work products before delivery
Responsible for team motivation and morale
Responsible for resource allocation within the team
Responsible for risk management within the team
Responsible for scope management within the team
Responsible for schedule management within the team
Responsible for budget management within the team
Responsible for configuration management within the team
The document discusses the project management process and inspection process. It provides details on the typical roles and responsibilities of a project manager, including planning, monitoring, communication facilitation, and postmortem analysis. It also outlines the steps for risk management, including identification, analysis, planning, and review. Finally, it describes the inspection process for reviewing work products, including planning, individual review, group review meetings, rework, and roles like moderator and scribe.
This document discusses risk management concepts including risk assessment, prioritization, and planning. It provides formulas for calculating risk exposure based on potential damage and probability of occurrence. It also includes qualitative descriptors for probability and impact levels and introduces a probability-impact matrix for risk analysis. Finally, it outlines different approaches for dealing with risks, such as acceptance, avoidance, reduction, transfer, and mitigation.
The document discusses various software project life cycle models and cost estimation techniques. It begins by describing agile methods like Scrum and Extreme Programming that emphasize iterative development, communication, and customer involvement. It then covers traditional models like waterfall and incremental development. Key estimation techniques discussed include function points, COCOMO, and analogy-based estimation. The document provides details on calculating sizes and estimating effort for different models.
The document discusses software project management activities and methodologies. It describes the typical activities covered in project management, including feasibility studies, planning, execution, and the software development life cycle. The software development life cycle includes requirements analysis, architecture design, coding and testing, integration, qualification testing, installation, and acceptance support. The document also discusses plans, methods, and methodologies, categorizing different types of projects, and identifying stakeholders.
The document discusses data retention policies and handling of confidential and sensitive data. It provides details on:
1) Data retention policies - their purpose, requirements, scope and how they are managed. Different retention periods are defined depending on the type of data.
2) Laws and regulations around data retention in India, particularly for telecommunication companies. Specific requirements for retaining call detail records, network logs, and other subscriber information are outlined.
3) Types of sensitive data, including personal, business, and classified information. Guidelines for properly handling sensitive data through access policies, authentication, training, and other security practices.
The document discusses principles of information architecture and its framework. It describes the responsibilities of information architects in collecting information from various sources, organizing large amounts of data on websites, understanding user needs, and testing user experiences. It also defines different dimensions of information architecture including contents, context, users. Components of information architecture discussed include labeling systems, navigation systems, organization systems, and searching systems.
The document discusses master data management (MDM) including its definition, need, and implementation process. MDM aims to create and maintain consistent and accurate master data across systems. It discusses key aspects like the different types of data, MDM architecture styles, and domains. The implementation involves identifying data sources, developing data models, deploying tools, and maintaining processes to manage master data effectively.
The document discusses various aspects of program security including types of flaws, malicious code, and controls against threats. It describes different types of flaws such as buffer overflows, incomplete mediation, and time-of-check to time-of-use errors. Malicious code like viruses, trojan horses, and worms are also explained. Controls during software development include following principles of modularity, encapsulation, and information hiding. Techniques like code reviews and testing aim to identify and fix flaws to enhance program security.
The document discusses IT6701 - Information Management, which covers topics such as database modeling, management and development, information governance, and information architecture. It describes objectives, units, database design, data modeling, entity relationship models, normalization, Java database connectivity, stored procedures, and big data technologies including Hadoop, HDFS, MapReduce, Hive and enhancements.
Quick sort is an internal sorting technique that uses the divide and conquer approach. It works by picking a pivot element and partitioning the array so that elements less than the pivot are moved left and greater elements right. The pivot is placed in its correct position, then quick sort is recursively applied to the left and right subarrays. It has a best case of O(n log n) and average case of O(n log n), but worst case of O(n^2).
Breadth first traversal (BFS) is a graph traversal algorithm that begins at a starting node and explores all neighboring nodes at the present distance from the node before proceeding to nodes at the next distance. It uses a queue to keep track of nodes to visit at each level. The key steps are to enqueue the starting node, dequeue nodes and enqueue any unvisited neighbors, repeating until the queue is empty. BFS can be used to check if a graph is connected or not. Depth first search (DFS) recursively explores as far as possible along each branch before backtracking. It involves marking the starting node visited, recursively searching adjacent unvisited nodes, and marking nodes visited along the way.
Binary search trees have nodes where the left child is less than the root node and the right child is greater than the root. Nodes are inserted by traversing the tree recursively to find an empty spot. Values are found by checking and traversing left or right based on whether the value is less than or greater than the current node. Minimum and maximum values are found by traversing all the way left or right. Nodes are deleted by checking if they have 0, 1, or 2 children and adjusting pointers accordingly or replacing with a child node.
The document defines and describes a stack data structure. A stack follows LIFO (last in, first out) and FILO (first in, last out) principles. Elements can be inserted using push and deleted using pop. Stacks have only one end for insertion/deletion and can be implemented using arrays or linked lists. The document provides code examples to implement stacks using arrays and linked lists and describes some applications of stacks like evaluating expressions and balancing symbols.
This document discusses using linked lists to represent polynomials and perform operations like addition and subtraction on them. It also discusses radix sort, which sorts integers based on their digits, and multi-linked lists, which have multiple links between nodes allowing for multiple lists to be embedded in a single data structure. Linked lists allow storing polynomial terms with coefficient and power, and traversing the lists to add/subtract terms with the same power and output a new polynomial list. Radix sort requires multiple passes equal to the largest number's digits to sort based on each digit place value. Multi-lists generalize linked lists by having nodes with multiple pointers connecting separate embedded lists.
An In-Depth Exploration of Natural Language Processing: Evolution, Applicatio...DharmaBanothu
Natural language processing (NLP) has
recently garnered significant interest for the
computational representation and analysis of human
language. Its applications span multiple domains such
as machine translation, email spam detection,
information extraction, summarization, healthcare,
and question answering. This paper first delineates
four phases by examining various levels of NLP and
components of Natural Language Generation,
followed by a review of the history and progression of
NLP. Subsequently, we delve into the current state of
the art by presenting diverse NLP applications,
contemporary trends, and challenges. Finally, we
discuss some available datasets, models, and
evaluation metrics in NLP.
Sri Guru Hargobind Ji - Bandi Chor Guru.pdfBalvir Singh
Sri Guru Hargobind Ji (19 June 1595 - 3 March 1644) is revered as the Sixth Nanak.
• On 25 May 1606 Guru Arjan nominated his son Sri Hargobind Ji as his successor. Shortly
afterwards, Guru Arjan was arrested, tortured and killed by order of the Mogul Emperor
Jahangir.
• Guru Hargobind's succession ceremony took place on 24 June 1606. He was barely
eleven years old when he became 6th Guru.
• As ordered by Guru Arjan Dev Ji, he put on two swords, one indicated his spiritual
authority (PIRI) and the other, his temporal authority (MIRI). He thus for the first time
initiated military tradition in the Sikh faith to resist religious persecution, protect
people’s freedom and independence to practice religion by choice. He transformed
Sikhs to be Saints and Soldier.
• He had a long tenure as Guru, lasting 37 years, 9 months and 3 days
Online train ticket booking system project.pdfKamal Acharya
Rail transport is one of the important modes of transport in India. Now a days we
see that there are railways that are present for the long as well as short distance
travelling which makes the life of the people easier. When compared to other
means of transport, a railway is the cheapest means of transport. The maintenance
of the railway database also plays a major role in the smooth running of this
system. The Online Train Ticket Management System will help in reserving the
tickets of the railways to travel from a particular source to the destination.
Data Communication and Computer Networks Management System Project Report.pdfKamal Acharya
Networking is a telecommunications network that allows computers to exchange data. In
computer networks, networked computing devices pass data to each other along data
connections. Data is transferred in the form of packets. The connections between nodes are
established using either cable media or wireless media.
2. UNIT III
SOFTWARE DESIGN
Design process – Design Concepts-Design
Model– Design Heuristic – Architectural
Design -Architectural styles, Architectural
Design, Architectural Mapping using Data
Flow- User Interface Design: Interface
analysis, Interface Design –Component level
Design: Designing Class based components,
traditional Components.
3. SOFTWARE DESIGN
Software design is a model of software which
translates the requirements into finished software
product.
Software design model consists of 4 designs:
Data/class Design
Architectural Design
Interface Design
Component Design
4. SOFTWARE DESIGN
Analysis model:
Scenario based elements
Class based elements
Behavioral elements
Flow oriented elements.
6. Software Design
Data/class design - Created by transforming the
analysis model class-based elements into classes and
data structures required to implement the software
Architectural design - defines the relationships among
the major structural elements of the software, it is
designed from the class-based elements and flow-
oriented elements of the analysis model.
7. Software Design
Interface design - describes how the software
elements, hardware elements, and end-users
communicate with one another, - analysis
model scenario-based elements, flow-oriented
elements, and behavioral elements.
8. Software Design
Why design is so important?
It provides us with representation of software that can be
assessed for quality.
Only way that can accurately translate a customer’s
requirements into a finished software product.
It serves as foundation for all software engineering
activities.
Without design difficult to assess: Risk , Test, Quality
9. Design Process
S/w design is an iterative process through
which requirements are translated into a
“blueprint” for constructing the s/w.
As design iteration occur, subsequent
refinement leads to design representation at
much lower levels of abstraction
10. Design Process
Characteristics of Good Design:
The good design should implement all the
requirements specified by the customer.
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.
11. Design Process
Characteristics of Good Design:
The design should be simple enough so that the
software can be understood easily by the developers,
testers and customers.
The design should provide a complete picture of the
software, addressing the data, functional, and
behavioral domains from an implementation
perspective.
12. Design Process
Quality Guideline:
The design architecture should be created using
following issues:
The design should be created using architectural styles and
patterns.
The implementation of design should be evolutionary, so
that testing can be performed at each phase of
implementation.
13. Design Process
Quality Guideline:
In the design the data, architecture, interfaces
and components should be clearly represented.
The design should be modular.
The data structure should be appropriately
chosen for the design of specific problem.
14. Design Process
Quality Guideline:
The components should be used in the design so
that functional independency can be achieved in
the design.
The interfaces in the design should be such that
the complexity between the connected
components of the system gets reduced.
15. Design Process
Quality Attributes (FURPS Model):
Functionality – It can be checked by assessing
the set of features and capabilities of the
functions.
Usability – It can be assessed by knowing the
usefulness of the system.
16. Design Process
Quality Attributes (FURPS Model):
Reliability – A measure of frequency and
severity of failure.
Performance – The response of the system.
Supportability – To adopt the enhancement or
changes made in the software.
18. Design Concepts
Abstraction:
At the highest level of abstraction – a solution
is stated in broad terms
At lower level of abstraction – a more detailed
description of the solution is provided
19. Design Concepts
Abstraction – Types:
Procedural Abstraction:
Sequence of instructions in the specific function.
Functionality of procedure is mentioned by its
implementation details are hidden.
Ex: Search the record
20. Design Concepts
Abstraction – Types:
Data Abstraction:
collection of data that describes a data object.
Search the record – record is the data
21. Design Concepts
Modularity:
Software is divided into separately named and
addressable components, sometimes called
modules, which are integrated to satisfy problem
requirement.
Modularity is the single attribute of software that
allows a program to be intellectually manageable.
22. Design Concepts
Modularity:
It leads to a “divide and conquer” strategy. – it is easier
to solve a complex problem when you break into a
manageable pieces.
Refer fig. that state that effort (cost) to develop an
individual software module does decrease if total
number of modules increase.
However as the no. of modules grows, the effort (cost)
associated with integrating the modules also grows.
24. Design Concepts
Modularity – Criteria:
Modular decomposability: A design method
provides a systematic mechanism for
decomposing the problem into sub-problems.
Modular Composability: It enables existing
design components to assembled into s new
system.
25. Design Concepts
Modularity – Criteria:
Modular Understandability: A module can be
understood as a standalone unit.
Modular Continuity: Changes to individual modules.
Modular protection: Effects are constrained within the
module.
26. Design Concepts
Architecture:
Software architecture suggest the overall
structure of the software and the ways in which
that structure provides conceptual integrity for
a system
27. Design Concepts
Architecture – Models:
Structural Model- represent architecture as an organized
collection of components
Framework model – shows the architectural framework and
corresponding applicability.
Dynamic model – address behavior of the program
architecture and indicating how system or structure
configuration may change as a function.
28. Design Concepts
Architecture – Models:
Process Model – focus on design of the business or
technical process that the system must accommodate.
Functional models – used to represent the functional
hierarchy of a system.
29. Design Concepts
Refinement:
Refinement is a process of elaboration
The architecture of a program is developed by
successively refining levels of procedural detail.
Refinement causes the designer to elaborate on the
original statement, providing more and more detail as
each successive refinement (elaboration) occurs.
30. Design Concepts
Pattern:
It acts as a design solution for a particular problem
occurring in specific domain.
Pattern can be usable
Pattern can be used for current work
Pattern can be used to solve similar kind of problem
with different functionality.
31. Design Concepts
Information Hiding:
It is the important property of modular design.
The modules are designed in such a way that
information contained in one module cannot be
accessible to the other module.
Only limited amount of information can be passed to
other module
32. Design Concepts
Information Hiding:
The intent of information hiding is to hide the details of
data structure and procedural processing behind a module
interface.
It gives benefits when modifications are required during
testing and maintenance because data and procedure are
hiding from other parts of software, unintentional errors
introduced during modification are less
33. Design Concepts
Functional Independence:
It can be achieved by developing the functional
modules with single-minded approach.
Independent modules are easier to maintain with
reduced error propagation.
Benefit: To achieve effective modularity
Qualitative criteria – Cohesion and Coupling
34. Design Concepts
Functional Independence – Cohesion:
The information hiding can be done.
It performs only “one task” in software
procedure with little interaction with other
modules.
35. Design Concepts
Functional Independence – Cohesion:
Coincidentally cohesive: The set of tasks are related
with each other modules loosely.
Logically cohesive: A module that performs the tasks
that are logically related with each other.
Temporal cohesive: The module in which the tasks
need to be executed in some specific time span.
36. Design Concepts
Functional Independence – Cohesion:
Procedural cohesive: when processing elements
of a module are related with one another and must
be executed in some specific order.
Communicational cohesion: when processing
elements of a module share the data.
37. Design Concepts
Functional Independence – Coupling:
It represents how the modules can be “connected” with
other module or with the outside world.
It is a measure of interconnection among modules in a
program structure.
It depends on the interface complexity between modules.
The goal is to strive for lowest possible coupling among
modules in software design.
39. Design Concepts
Functional Independence – Coupling:
Data Coupling: It is possible by parameter passing or data
interaction.
Control coupling: It shares related control data
Common coupling: common data or a global data is shared
among the modules
Content coupling: It occurs when on module makes use of
data or control information maintained in another module.
40. Design Concepts
Refactoring:
For simplifying the design without changing the
function or behavior.
“The process of changing a software system in
such a way that the external behavior of the
design do not get changed, however the internal
structure gets improved. ”
41. Design Concepts
Refactoring – Benefits:
The redundancy can be achieved.
Inefficient algorithms can be eliminated
Inaccurate data structures can be removed or
replaced.
42. Design Concepts
Design Classes:
The classes that describe some elements of problem
domain, focus on various aspects of problem from user’s
point of view.
To refine the analysis classes by providing the detail
design, so that further implementation can be done easily.
To create new set of classes for implementing the
infrastructure of the software.
43. Design Concepts
Design Classes – Types:
User interface class: A visual representation of
the HCI.
Business Domain class: Identify the attributes
and service that are needed to implement some
elements of business domain.
44. Design Concepts
Design Classes – Types:
Process Class: It implements lower level
business abstractions used by the business
domain.
Persistent Class: represent the data store.
45. Design Concepts
Design Classes – Types:
System Class: responsible for software
management and control functions that are
used for system operation.
Characteristics: Complete and efficient, High
cohesion and low coupling.
46. Design Model
Data design elements
The data design element produced a model of data that
represent a high level of abstraction.
This model is then more refined into more implementation
specific representation which is processed by the computer
based system.
The structure of data is the most important part of the
software design.
47. Design Model
Architectural design elements
The architecture design elements provides us overall
view of the system.
The architectural design element is generally
represented as a set of interconnected subsystem that
are derived from analysis packages in the requirement
model.
48. Design Model
Architectural design elements-Sources
The information about the application domain to built
the software.
Requirement model elements like data flow diagram or
analysis classes, relationship and collaboration
between them.
The architectural style and pattern as per availability.
49. Design Model
Interface design elements:
The interface design elements for software
represents the information flow within it and out of
the system.
They communicate between the components
defined as part of architecture.
50. Design Model
Interface design elements – Elements:
The user interface - GUI
The external interface to the other systems, networks
etc.
The internal interface between various components –
Ex: Classes can communicate with each other by
operations or by passing messages
51. Design Model
Component level diagram elements:
The component level design for software is similar to the
set of detailed specification of each room in a house.
It describes the internal details of the each software
component.
The processing of data structure occurs in a component
and an interface which allows all the component
operations.
53. Design Model
Deployment level design elements:
It shows the software functionality and subsystem
that allocated in the physical computing
environment which support the software.
55. Design Heuristic
Evaluate the first iteration of the program
structure to reduce the coupling and improve
cohesion:
Exploding and imploding modules
56. Design Heuristic
Attempt to minimize the structures with high
fan-out and strive for fan-in as depth increases:
Fan-out: number of immediate subordinates to the
module
Fan-in: number of immediate relations the module
have.
57. Design Heuristic
Keep scope of the effect of a module within
the scope of control of that module:
Module ‘A’ should not affect the module ‘b’
58. Design Heuristic
Evaluate the module interfaces to reduce
complexity and redundancy and improve
consistency.
Define module whose function is predictable but
avoid modules that are too restrictive.
Strive for controlled entry modules by avoiding
pathological connections.
59. Introduction to Architectural Design
A design created to represent the data and
program components that are required to build the
computer based systems.
It considers the system’s structure and properties
of the system components.
The person who is responsible to design –
Software Architect.
60. Introduction to Architectural Design
Software Architecture:
“A structure of systems which consists of various
components, externally visible properties of these
components and the inter-relationship among these
components”
61. Introduction to Architectural Design
Software Architecture:
To establish the overall structure of software
system.
The link between design specification and actual
design process.
62. Introduction to Architectural Design
Software Architecture – Structural Partitioning:
Horizontal partitioning:
It defines separate branches of the modular hierarchy
for each major program function.
It defines three partitions—input, data transformation
(often called processing) and output.
64. Introduction to Architectural Design
Software Architecture – Structural Partitioning:
Horizontal partitioning – Benefits:
software that is easier to test
software that is easier to maintain
propagation of fewer side effects
software that is easier to extend
65. Introduction to Architectural Design
Software Architecture – Structural
Partitioning:
Vertical partitioning: It suggests the control
and work should be distributed top-down in
program structure
66. Introduction to Architectural Design
Software Architecture – Structural Partitioning:
Vertical partitioning:
Top-level modules should perform control functions
and do little actual processing work.
Low-level modules in the structure should be the
workers, performing all input, computation, and output
tasks.
67. Data Design
The model of the data that is represented at
the high level of abstraction.
Elements:
Data Object: Use ER diagram or Data Dictionary
Databases
Data warehouses
68. Data Design
Guideline for data design:
Apply systematic analysis on data
Identify the data structures and related operations
Establish data dictionary
Define the low level design decisions until late in
the design process
69. Data Design
Guideline for data design:
Use information hiding in the design of the data
structures
Apply a library of useful data structures and
operations
Use a software design and programming to support
data specification and abstraction
70. Architectural Style
It is a pattern for creating the system
architecture for given problem.
Components: It performs a function required
by a system. Ex: a database, computational
modules, clients and servers.
71. Architectural Style
Connectors: It enables “communication, co-
ordinations and cooperation” among components.
Constraints that define how components can be
integrated to form the system.
Semantic models that enable a designer to
understand the overall properties of a system.
73. Architectural Style
Data-centered architecture:
A data store (e.g., a file or database) resides at the
center of this architecture and is accessed frequently
by other components that update, add, delete, or
otherwise modify data within the store.
Client software accesses a central repository without
any change in data.
74. Architectural Style
Data-centered architecture:
It posses the property of interchangeability.
Any component from the architecture can be
replaced by a new component without affecting the
working of other components.
The data can be passed among components.
75. Architectural Style
Data Flow architecture – Pipe and Filter:
When input data are to be transformed through a series of
computational components into output data.
76. Architectural Style
Data Flow architecture – Pipe and Filter:
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.
77. Architectural Style
Data Flow architecture – Batch Sequential:
If the data flow degenerates into a single line of
transforms, it is termed batch sequential.
79. Architectural Style
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.
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
80. Architectural Style
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
82. Architectural Style
Layered Architecture:
A number of different layers are defined, each
accomplishing operations that progressively become closer
to the machine instruction set.
At the outer layer, components examine user interface
operations.
83. Architectural Style
Layered Architecture:
At the inner layer, components examine operating system
interfacing.
Intermediate layers provide utility services and application
software functions.
84. Architectural Patterns
An approach for handling behavioural characteristics of
software systems.
Domains:
Concurrency: Handling multiple tasks in parallel.
Persistence: The data used in earlier execution can be made
available further by storing it in files.
Distribution: The system components communicate with each
other.
85. Architectural Design
The design should define the external entities (other systems,
devices, people) that the software interacts with and the nature
of the interaction.
This information can generally be acquired from the
requirements model and all other information gathered during
requirements engineering.
The designer specifies the structure of the system by defining
and refining software components that implement each
archetype.
86. Architectural Design
Representing the System in Context
At the architectural design level, a software architect uses
an architectural context diagram (ACD) to model the
manner in which software interacts with entities external to
its boundaries.
88. Architectural Design
Representing the System in Context
Super ordinate systems : systems that use the target system as
part of some higher-level processing scheme.
Subordinate systems: Systems that are used by the target system
and provide data or processing that are necessary to complete
target system functionality.
Peer-level systems:Systems that interact on a peer-to- peer basis.
Actors: entities (people, devices) that interact with the target
system by producing or consuming information.
89. Architectural Design
Defining Archetypes
An archetype is a class or pattern that represents a core
abstraction that is critical to the design of an architecture
for the target system.
A relatively small set of entities is required to design even
relatively complex systems.
For example, an archetype for a car: wheels, doors, seats,
engine In software engineering
90. Architectural Design
Defining Archetypes:
Node : Represents a cohesive collection of input and
output elements.
Detector : An abstraction that covers all sensing
equipment that feeds information into the target
system.
91. Architectural Design
Defining Archetypes:
Indicator: An abstraction that represents all
mechanisms (e.g., alarm siren, flashing lights, bell)
for indicating that an alarm condition is occurring.
Controller. An abstraction that describes the
mechanism that allows the arming (Supporting) or
disarming of a node
92. Architectural Design
Refining the Architecture into Components
As the software architecture is refined into components.
Analysis classes represent entities within the application
(business) domain that must be addressed within the
software architecture.
In some cases (e.g., a graphical user interface), a
complete subsystem architecture with many components
must be designed.
93. Architectural Design
Refining the Architecture into Components
External communication management
Control panel processing
Detector management
Alarm processing
94. Architectural Design
Describing Instantiations of the System
The overall structure of the system is apparent, and the
major software components have been identified.
However, further refinement is still necessary.
To accomplish this, an actual instantiation of the
architecture is developed. It means, again it simplify by
more details.
95. Architectural Mapping using Data
Flow
Transform flow: A sequence of paths which forms
transition in which input data are transformed into
output data.
Transaction flow: The information flow in which
single data item triggers the overall information flow
along the multiple paths.
96. Architectural Mapping using Data
Flow
Transform flow – Automated Railway Reservation
System:
Registers for the using the system
Make the train enquiry
Can view the status of reservation by entering PNR number.
Can make the reservations
Can cancel the reservations
97. Architectural Mapping using Data
Flow
Transform flow:
A collection of design steps using which a DFD
containing transform flow characteristics is mapped
into specific architectural style.
98. Architectural Mapping using Data
Flow
Transform flow:
Step 1: Review fundamental system model to
identify information flow:
Obtained from System Specification and SRS.
99. Architectural Mapping using Data
Flow
Transform flow - Step 2: Review and refine the data
flow diagram for software:
100. Architectural Mapping using Data
Flow
Transform flow - Step 2: Review and refine the data
flow diagram for software:
101. Architectural Mapping using Data
Flow
Transform flow - Step 3: Determine if the DFD has
the transform or transaction flow characteristics:
The information flow within the system is usually
represented as transform flow.
If draw level 3 DFD for the process Make Reservation
then the transformation flow can be identified.
103. Architectural Mapping using Data
Flow
Transform flow - Step 4: Isolate the transform center
by specifying incoming and outgoing flow
boundaries:
Separate out the incoming and outgoing flow boundaries
and the transform center can be identified.
105. Architectural Mapping using Data
Flow
Transform flow - Step 5: Perform first level factoring:
It results in top down architecture.
Top level – Perform decision making
Low level – perform most input, computation and output.
Middle level – perform some control and some amount
of work.
107. Architectural Mapping using Data
Flow
Transform flow
Step 6: Perform second level factoring:
Individual bubble of DFD is mapped into appropriate
module within architecture
109. Architectural Mapping using Data
Flow
Transform flow
Step 7: Refine the first iteration architecture using
design heuristics for improved software quality:
Refined by applying the module independency
It always follows “High Cohesion and Low Coupling”
110. Architectural Mapping using Data
Flow
Transform flow - Step 7: Refine the first iteration
architecture using design heuristics for improved
software quality:
111. Architectural Mapping using Data
Flow
Transaction flow :
A single data item leads to one or more information flows.
Each information flow specifies some distinct
functionality – Transaction center.
112. Architectural Mapping using Data
Flow
Transaction flow – Design Steps:
Review fundamental system model to identify information
flow.
Review and refine the data flow diagram for software.
Determine if the DFD has the transform or transaction
flow characteristics.
113. Architectural Mapping using Data
Flow
Transaction flow – Design Steps:
Identify the transaction center and flow
characteristics along each of the action paths.
To identify the location of transaction centre.
Ex: User selects Book Ticket, Ticket Enquiry options.
There can be multiple action paths fanning out from the
transaction center.
114. Architectural Mapping using Data
Flow
Transaction flow – Design Steps - Identify the
transaction center and flow characteristics along each
of the action paths.
115. Architectural Mapping using Data
Flow
Transaction flow – Design Steps:
Map DFD into transaction processing structure:
The identified transaction flow is mapped into an
architecture that contains an incoming branch and a
dispatcher branch.
The corresponding bubbles on incoming path are mapped
into the appropriate modules.
116. Architectural Mapping using Data
Flow
Transaction flow – Design Steps - Map DFD into
transaction processing structure:
117. Architectural Mapping using Data
Flow
Transaction flow – Design Steps:
Factor and refine the transaction structure and
structure of each action path:
Action path related sub structure is developed.
118. Architectural Mapping using Data
Flow
Transaction flow – Design Steps- Factor and refine
the transaction structure and structure of each action
path:
119. Architectural Mapping using Data
Flow
Transaction flow – Design Steps:
Refine the first iteration architecture using design
heuristics for improved software quality :
Refined by applying the module independency
It always follows “High Cohesion and Low Coupling”
120. User Interface Design
User interface design creates an effective
communication medium between a human and a
computer.
Follows 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.
121. User Interface Design
Advantages:
The user interface systems provide fast and intuitive
interactions to the user. The new user can easily operate the
system.
As in user interface design, menus are provided, it avoids typing
mistakes.
The user interface helps in simple data entry.
It provides the flexibility in switching from one task to another.
122. User Interface Design
Golden Rules:
Place the user in control
Reduce the user’s memory load
Make the interface consistent
123. User Interface Design
Golden Rules - Place the user in control:
Define interaction modes in a way that does not force
a user into unnecessary or undesired actions
An interaction mode is the current state of the interface.
Provide for flexible interaction
Because different users have different interaction
preferences, choices should be provided
124. User Interface Design
Golden Rules - Place the user in control:
Allow user interaction to be interruptible and undoable.
Even when involved in a sequence of actions, the user should be
able to interrupt the sequence to do something else.
Allow user to customize the interaction
Users often find that they perform the same sequence of
interactions repeatedly.
125. User Interface Design
Golden Rules - Place the user in control:
Hide technical internals from the casual user
The interface should never require that the user interact at a level
that is “inside” the machine.
The objects appearing on the screen should be interactive
with the user
User should be in position to adjust the object appearing on the
screen.
126. User Interface Design
Golden Rules - Reduce the User’s Memory Load:
Reduce demand on short-term memory.
The interface should be designed to reduce the requirement
to remember past actions and results.
Establish meaningful defaults
a “reset” option should be available, enabling the
redefinition of original default values.
127. User Interface Design
Golden Rules - Reduce the User’s Memory Load:
Define shortcuts that are intuitive
Shortcuts are required in the user interface
The visual layout of the interface should be realistic
It helps a causal user to handle the system with ease.
Disclose the information gradually
The interface should be organized hierarchically.
128. User Interface Design
Golden Rules - Make the Interface Consistent:
The interface should present and acquire information in a
consistent fashion.
All visual information is organized according to a design standard that
is maintained throughout all screen displays.
Input mechanisms are constrained to a limited set that are used
consistently throughout the application
Navigating from task to task are consistently defined and implemented
129. User Interface Design
Golden Rules - Make the Interface Consistent:
Allow the user to put the current task into a meaningful
context.
A user interface with proper indicators
Maintain consistency across a family of applications.
A set of applications (or products) should all implement the same
design rules so that consistency is maintained for all interaction.
130. User Interface Design
Golden Rules - Make the Interface Consistent:
If certain standards are maintained in previous model
of application do not change it until and unless it is
necessary.
Once a particular interactive sequence has become a de
facto standard (e.g., the use of alt-S to save a file)
131. User Interface Design
Models:
User model — To understand the user who is using the
system.
The profile of all end users of the system ( Considering
Age, Gender, Educational and cultural background)
Users: Novice, Knowledgeable and intermittent and
Knowledgeable and frequent
132. User Interface Design
Models:
Design Model –Data, Architectural, Interface and
Procedural representation of the software.
Requirement specification must be used properly to
set the system constraints.
133. User Interface Design
Models:
Mental Model – The representation of what user
thinks about the system?
If the user is knowledgeable then more complete
description of the system can be obtained that of
novice user.
134. User Interface Design
Models:
Implementation Model – It generates the look and
feel of interface.
User can feel comfortable with the developed system
135. User Interface Design – The Process
Activities:
Environment analysis and modeling
Interface Design
Implementation
Interface validation
136. User Interface Design – The Process
Activities - Environment analysis and modeling:
Factors:
User profile is analysed to understand the user and to elicit the
requirements.
The tasks that are required to carry out desired functionality
are identified and analysed.
Environment which involves the physical work environment.
137. User Interface Design – The Process
Activities – Interface Design: All the interface
objects and corresponding actions of each task are
defined.
Implementation: Creation of prototype using which
the interface scenarios can be evaluated.
Validation: To validate the interface for its correct
performance.
138. User Interface Design
Interface Analysis:
Interface analysis means understanding
The people (end-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 environment in which these tasks will be conducted.
139. User Interface Design
Interface Analysis:
User Analysis – what the user wants from the UI:
User interviews: Representatives from software team
meet the end user to better understand the user needs,
motivations and many other issues.
Meeting are conducted for this purpose.
140. User Interface Design
Interface Analysis - User Analysis – what the user
wants from the UI:
Sales input:
Sales people interact with the users regularly and collect
the information
Users are categorized in groups and thereby their
requirements are better understood.
141. User Interface Design
Interface Analysis - User Analysis – what the user
wants from the UI:
Marketing input:
To understand the usage of software
142. User Interface Design
Interface Analysis - User Analysis – what the user
wants from the UI:
Support input:
Support staff keeps a regular interaction with the user
interaction for knowing the certain things likings and
dislikes of the user.
143. User Interface Design
User Analysis:
Are users trained professionals, technician, clerical, or
manufacturing workers?
What level of formal education does the average user have?
Are the users capable of learning from written materials or have
they expressed a desire for classroom training?
Are users expert typists or use of keyboard?
What is the age range of the user community?
144. User Interface Design
User Analysis:
Will the users be represented predominately by one gender?
How are users compensated for the work they perform?
Do users work normal office hours or do they work until the job
is done?
Is the software to be an integral part of the work users do or will
it be used only occasionally?
What is the primary spoken language among users?
145. User Interface Design
Task Analysis and modeling:
What work will the user perform in specific circumstances?
What tasks and subtasks will be performed as the user does the
work?
What specific problem domain objects will the user manipulate
as work is performed?
What is the sequence of work tasks—the workflow?
What is the hierarchy of tasks?
146. User Interface Design
Task Analysis and modeling – Techniques:
Use cases: It describes interaction between user and
system.
It shows how the end user performs specific work
related task.
147. User Interface Design
Task Analysis and modeling – Techniques:
Task Elaboration – Stepwise refinement of the processing task
is done.
Object Elaboration – Extract information about the physical
objects. These objects are further classified into classes.
Workflow analysis defines how a work process is completed
when several people (and roles) are involved. Ex: Swimlane
Diagram.
148. User Interface Design
Task Analysis and modeling – Techniques:
Hierarchical representation – The task hierarchy for each
user type should be specified.
Fill reservation Form:
Personal Info: Specify name, Specify age, Desired source city,
Desired destination city, Date and time
Reservation details: Age, Source City, Destination City, Seat
numbers, Type of reservation and Name of the train.
149. User Interface Design
Analysis of Display Content:
The display contents can be spreadsheets, pictures, a graph
and audio or video files.
The format and nature of the display contents are
considered.
150. User Interface Design
Analysis of Display Content:
Are different types of data assigned to consistent
geographic locations on the screen.
Can the user customize the screen location for content?
Is proper on-screen identification assigned to all content?
If a large report is to be presented, how should it be
partitioned for ease of understanding?
151. User Interface Design
Analysis of Display Content:
Will mechanisms be available for moving directly to summary
information for large collections of data.
Will graphical output be scaled to fit within the bounds of the
display device that is used?
How will color to be used to enhance understanding?
How will error messages and warning be presented to the user?
152. User Interface Design
Analysis of work environment:
There may be interactive presentation of the information,
proper lighting, good display height, easy keyboard access,
proper sitting arrangement.
153. User Interface Design
Interface Design:
Using information developed during interface analysis, define
interface objects and actions (operations).
Define events (user actions) that will cause the state of the user
interface to change. Model this behavior.
Depict each interface state as it will actually look to the end-user.
Indicate how the user interprets the state of the system from
information provided through the interface.
154. User Interface Design
User interface Design Pattern:
Pattern Description
TopLevelNavigation It enables direct navigation to any of the system’s
major functions
Fill-in-the-Blanks Allow alphanumeric data to be entered in a “text box.”
SortableTable Display a long list of records that can be sorted by
selecting a toggle mechanism for any column label.
SimpleSearch ability to search a website
Wizard the completion of the task through a series of simple
window displays.
ShoppingCart Provides a list of items selected for purchase
ProgressIndicator Provides an indication of progress when an operation
takes longer than n seconds
155. User Interface Design
Design Issues:
System Response Time:
It is measured from the point at which the user performs
some control action until the software responds with
desired output or action.
Characteristics – Length: Amount of time taken by the
system to respond
Variability: the deviation from average response time
156. User Interface Design
Design Issues:
Help facilities:
User manuals
Online help facilities that enable a user to get a question
answered or resolve a problem without leaving the interface
157. User Interface Design
Design Issues -Error handling –Message Characteristics:
The message should describe the problem in terminology that
the user can understand
There should be some useful message along with error in order
to recover from the error.
There should be some audible or visual cue along with the error
message.
There should not be any negative impact of error on the user.
The wording of the error should be carefully used
158. User Interface Design
Design Issues:
Menu and command labeling:
The typed command was once the most common mode of
interaction between user and system software
The use of window-oriented, point-and pick interfaces has
reduced reliance on typed commands
159. User Interface Design
Design Issues:
Application accessibility:
Software engineers must develop a mechanism by which
the most frequently required applications must be availed
easily.
Accessibility for users who may be physically challenged
is an imperative for ethical, legal, and business reasons.
160. User Interface Design
Design Issues:
Internationalization:
“globalized” software - user interfaces should be designed to
accommodate a generic core of functionality that can be
delivered to all who use the software.
Localization features enable the interface to be customized for a
specific market.
The Unicode standard has been developed for characters and
symbols.
161. Component Level Design
OMG UML Specification defines a component as
“a modular, deployable, and replaceable part of a
system that encapsulates implementation and exposes
a set of interfaces”
162. Component Level Design
Designing Class based Components
Component is represented as a part of architectural model. It
collects the information about the system as a part of analysis
model.
OO View: a component contains a set of collaborating classes
The detailed description of attributes, operations and interfaces
of these infrastructure classes is required during the system
building.
163. Component Level Design
Design Principles:
Open-Closed Principle: A module should be open for extension but
closed for modification.
Liskov Substitution Principle: Subclasses should be substitutable
for their base classes.
Dependency Inversion Principle: Depend on abstractions. Do not
depend on concrete component.
Interface Segregation Principle: Many client-specific interfaces are
better than one general purpose interface
164. Component Level Design
Design Guidelines:
Components:
Naming conventions should be established for components
that are specified as part of the architectural model and then
refined and elaborated as part of the component-level
model.
165. Component Level Design
Design Guidelines:
Interfaces - provide important information about
communication and collaboration.
Dependencies and Inheritance:
Dependencies from left to right - inheritance from
bottom(derived classes) to top(base classes)
166. Structured Programming
Three constructs:
Sequence: A linear processing of the statements
Condition: To test the logical conditions
Repetition: To denote the looping
Advantages:
reduces program complexity
enhances readability, testability and maintainability
168. Structured Programming
Graphical Design Notations –Box Diagram:
Nassi-Shneiderman charts, N-S charts, or Chapin charts –
Characteristics:
Functional domain (that is, the scope of repetition or if-then-else) is
well defined and clearly visible as a pictorial representation
Arbitrary transfer of control is impossible
The scope of local and/or global data can be easily determined
Recursion is easy to represent
170. Structured Programming
Tabular Design Notations:
Decision tables provide a notation that translates actions and conditions
into a tabular form.
Sections:
The upper left-hand quadrant contains a list of all conditions.
quadrant contains a list of all actions
The right-hand quadrants form a matrix that indicates condition
combinations
the corresponding actions that will occur for a specific combination
172. Structured Programming
Tabular Design Notations:
List all actions that can be associated with a specific procedure
(or module).
List all conditions (or decisions made) during execution of the
procedure.
Associate specific sets of conditions with specific actions,
eliminating impossible combinations
Define rules by indicating what action(s) occurs for a set of
conditions
173. Structured Programming
Program Design Language:
It is a pseudo code or structured English.
to translate the design into the programming language.
174. Structured Programming
Program Design Language:
Easy to combine with source code
Can be represented in great detail
Machine readable, no need for graphics input
Graphics can be generated from PDL
Enables declaration of data as well as procedure
Easier to review and maintain