! Class II Year / CSE (04 Semester) Subject Code CS6403 Subject SOFTWARE ENGINEERING Prepared By P.Ramya Lesson Plan for Design Process and Design concept Time: 50 Minutes Lesson. No Unit – III Lesson No: 1,2/11 1.Content List: Design Process and Design concept 2.Skill addressed: • Understand the Concepts of Design Process and Design concept 3.Objectives of this Lesson Plan: To enable students to understand the Concept of basic Design Process and Design concept 4.Outcome(s): Understand And Analyse the basic concepts of Design Process and Design concept 5.Link sheet: 1. Mention some of design principles. 2. State procedural abstraction. 3. What does abstraction contains? 6.Evocation: (5 Minutes) WWW . STUDENTSFOCUS . COM WWW.STUDENTSFOCUS.COM www.studentsfocus.com
30
Embed
- SE/notes... · Class II Year / CSE (04 Semester) Subject Code CS6403 Subject SOFTWARE ENGINEERING Prepared By P.Ramya Lesson Plan for …
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
����� �������� ����������� ��!� �
Class II Year / CSE (04 Semester)
Subject Code CS6403
Subject SOFTWARE ENGINEERING
Prepared By P.Ramya
Lesson Plan for Design Process and Design concept
Time: 50 Minutes
Lesson. No Unit – III Lesson No: 1,2/11
1.Content List: Design Process and Design concept
2.Skill addressed:
• Understand the Concepts of Design Process and Design concept
3.Objectives of this Lesson Plan:
To enable students to understand the Concept of basic Design Process and Design
concept
4.Outcome(s):
Understand And Analyse the basic concepts of Design Process and Design concept
5.Link sheet:
1. Mention some of design principles.
2. State procedural abstraction.
3. What does abstraction contains?
6.Evocation: (5 Minutes)
WWW . STUDENTSFOCUS . COM
WWW.STUDENTSFOCUS.COM
www.studentsfocus.com
����� �������� ����������� ��!� �
Subject introduction (40 Minutes):Topics:
• Design process
• Design principle
• Design concepts
• Abstraction
• Refinement
7.Lecture Notes
Design ProcessDesign process is a sequence of steps carried through which the requirement are translated into asystem or software modelDesign products1. In architectural design the subsystem components can be identified.
2. The abstract specification is used to specify the subsystems.
3. The interfaces between the subsystems are designed, which is called interface
4. design.
5. In component design of subsystems components is done ..
6. The data structure is designed to hold the data
7. For performing the required functionality, the appropriate algorithm is designed.
WWW . STUDENTSFOCUS . COM
www.studentsfocus.com
����� �������� ����������� ��!� �
Design PrincipleDavis suggested a set of principles for software design as:
� The design process should not suffer from "tunnel vision",
� The design should be traceable to the I1nalysis model,
� The design should not reinvent the wheel.
� The design should “minimize the intellectual distance” between the software and theproblem in the real world
� The design should exhibit uniformity and integration.
� The design should be structured to accommodate change.
� The design should be structured to degrade gently.
� Design is not coding.
� The design should be assessed for quality.
The design should be reviewed to minimize conceptual errors.Design Principles – 1:• Process should not suffer from tunnel vision – consider alternative approaches• Design should be traceable to analysis model• Do not try to reinvent the wheel use design patterns ie reusable components• Design should exhibit both uniformity and integration• Should be structured to accommodate changesDesign Principles – 2 :• Design is not coding and coding is not design• Should be structured to degrade gently, when bad data, events, or operating conditions areencountered• Needs to be assessed for quality as it is being created• Needs to be reviewed to minimize conceptual (semantic) errorsDesign Concepts -1 :• Abstraction allows designers to focus on solving a problem without being concerned aboutirrelevant lower level details .Procedural abstraction is a named sequence of instructions that hasa specific and limited functione.g open a door
• Open implies a long sequence of procedural stepsdata abstraction is collection of data that describes a data objecte.g door type, opening mech, weight,dimenDesign Concepts -2 :• Design Patterns description of a design structure that solves a particular design problem withina specific context and its impact when applied
Design Concepts -3 :• Software Architecture
� overall structure of the software components and the ways in which that structure� provides conceptual integrity for a system
Design Concepts -4 :� • Information Hiding information (data and procedure) contained within a module is
inaccessible to modules that have no need for such information� • Functional Independence achieved by developing modules with single-minded purpose
and an aversion to excessive interaction with other models • Objects encapsulate bothdata and data manipulation procedures needed to describe the content and behavior of areal world entity Class generalized description (template or pattern) that describes acollection of similar objects
� • Inheritance provides a means for allowing subclasses to reuse existing superclass dataand procedures; also provides mechanism for propagating changes
Design Concepts – 5:• Messages the means by which objects exchange information with one another• Polymorphism
� a mechanism that allows several objects in an class hierarchy to have different methodswith the same name
� instances of each subclass will be free to respond to messages by calling their ownversion of the method
� Abstractiono Procedural abstraction – a sequence of instructions that have a specific and
limited functiono Data abstraction – a named collection of data that describes a data object
� Architectureo The overall structure of the software and the ways in which the structure provides
conceptual integrity for a systemo Consists of components, connectors, and the relationship between them
� Patternso A design structure that solves a particular design problem within a specific
contexto It provides a description that enables a designer to determine whether the pattern
is applicable, whether the pattern can be reused, and whether the pattern can serveas a guide for developing similar patterns
� Modularityo Separately named and addressable components (i.e., modules) that are integrated
to satisfy requirements (divide and conquer principle)o Makes software intellectually manageable so as to grasp the control paths, span of
reference, number of variables, and overall complexity� Information hiding
o The designing of modules so that the algorithms and local data contained withinthem are inaccessible to other modules
o This enforces access constraints to both procedural (i.e., implementation) detailand local data structures
� Functional independenceo Modules that have a "single-minded" function and an aversion to excessive
interaction with other moduleso High cohesion – a module performs only a single tasko Low coupling – a module has the lowest amount of connection needed with other
modules
8.Textbook:T1: Roger S. Pressman, “Software Engineering – A practitioner’s Approach”, SixthEdition, McGraw-Hill International Edition, 2005
� (Vertically) The abstraction dimension represents the level of detail as eachelement of the analysis model is transformed into the design model and theniteratively refined
• Elements of the design model use many of the same UML diagrams used in the analysismodel
o The diagrams are refined and elaborated as part of the designo More implementation-specific detail is providedo Emphasis is placed on
� Architectural structure and style� Interfaces between components and the outside world� Components that reside within the architecture
� Design model elements are not always developed in a sequential fashiono Preliminary architectural design sets the stageo It is followed by interface design and component-level design, which
often occur in parallel� The design model has the following layered elements
o Data/class designo Architectural designo Interface designo Component-level design. A fifth element that follows all of
the others is deployment-level designDesign Elements
� Data/class designo Creates a model of data and objects that is represented at a high level of
abstraction� Architectural design
o Depicts the overall layout of the software� Interface design
o Tells how information flows into and out of the system and how it iscommunicated among the components defined as part of the architecture
o Includes the user interface, external interfaces, and internal interfaces� Component-level design elements
o Describes the internal detail of each software component by way of datastructure definitions, algorithms, and interface specifications
� Deployment-level design elementso Indicates how software functionality and subsystems will be allocated
within the physical computing environment that will support the softwareDesign Heuristics for Effective Modularity
o Evaluate the first iteration of the program structure to reduce coupling andimprove cohesion.
o Attempt to minimize structures with high fan-out; strive for fan-in as structuredepth increases.
o Keep the scope of effect of a module within the scope of control for that module.o Evaluate module interfaces to reduce complexity, reduce redundancy, and
improve consistency.o Define modules whose function is predictable and not overly restrictive (e.g. a
module that only implements a single subfunction).o Strive for controlled entry modules, avoid pathological connection (e.g. branches
� An early stage of the system design process.� Represents the link between specification and design processes.� Often carried out in parallel with some specification activities.� It involves identifying major system components and their communications.
Advantages of explicit architecture• Stakeholder communication
� Architecture may be used as a focus of discussion by systemstakeholders.
• System analysis� Means that analysis of whether the system can meet its non-functional
requirements is possible.• Large-scale reuse
� The architecture may be reusable across a range of systems.
Architecture and system characteristics� Performance
o Localise critical operations and minimise communications. Use large ratherthan fine-grain components.
� Securityo Use a layered architecture with critical assets in the inner layers.
� Safetyo Localise safety-critical features in a small number of sub-systems.
� Availabilityo Include redundant components and mechanisms for fault tolerance.
� Maintainabilityo Use fine-grain, replaceable components.
Architectural conflicts� Using large-grain components improves performance but reduces maintainability.� Introducing redundant data improves availability but makes security more difficult.� Localising safety-related features usually means more communication so degraded
performance.
System structuring� Concerned with decomposing the system into interacting sub-systems.� The architectural design is normally expressed as a block diagram presenting an
overview of the system structure.� More specific models showing how sub-systems share data, are distributed and
interface with each other may also be developed.
Packing robot control systemBox and line diagrams
� Very abstract - they do not show the nature of component relationships nor theexternally visible properties of the sub-systems.
� However, useful for communication with stakeholders and for project planning.
Architectural design decisions� Architectural design is a creative process so the process differs depending on the type
of system being developed.� However, a number of common decisions span all design processes.� Is there a generic application architecture that can be used?� How will the system be distributed?� What architectural styles are appropriate?� What approach will be used to structure the system?� How will the system be decomposed into modules?� What control strategy should be used?� How will the architectural design be evaluated?� How should the architecture be documented?
Architecture reuse� Systems in the same domain often have similar architectures that reflect domain
concepts.� Application product lines are built around a core architecture with variants that satisfy
particular customer requirements.
Architectural styles� The architectural model of a system may conform to a generic architectural model or
style.� An awareness of these styles can simplify the problem of defining system
� However, most large systems are heterogeneous and do not follow a singlearchitectural style.
Architectural models� Used to document an architectural design.
Static structural model that shows the major system components.� Dynamic process model that shows the process structure of the system.� Interface model that defines sub-system interfaces.� Relationships model such as a data-flow model that shows sub-system relationships.� Distribution model that shows how sub-systems are distributed across computers.
System organisation� Reflects the basic strategy that is used to structure a system.� Three organisational styles are widely used:
• A shared data repository style;• A shared services and servers style;• An abstract machine or layered style.
The repository model� Sub-systems must exchange data. This may be done in two ways:
� Shared data is held in a central database or repository and may beaccessed by all sub-systems;
� Each sub-system maintains its own database and passes data explicitlyto other sub-systems.
� When large amounts of data are to be shared, the repository model of sharing is mostcommonly used.
CASE toolset architecture� Repository modelAdvantages� Efficient way to share large amounts of data;� Sub-systems need not be concerned with how data is produced Centralised
management e.g. backup, security, etc.� Sharing model is published as the repository schema.DisadvantagesSub-systems must agree on a repository data model. Inevitably a compromise;� Data evolution is difficult and expensive;� No scope for specific management policies;� Difficult to distribute efficiently.
Client-server model� Distributed system model which shows how data and processing is distributed across
a range of components.� Set of stand-alone servers which provide specific services such as printing, data
management, etc.� Set of clients which call on these services.� Network which allows clients to access servers.
Advantages• Distribution of data is straightforward;• Makes effective use of networked systems. May require cheaper hardware;• Easy to add new servers or upgrade existing servers.
Disadvantages• No shared data model so sub-systems use different data organisation. Data interchange maybe inefficient;• Redundant management in each server;• No central register of names and services - it may be hard to find out what servers andservices are available.
Abstract machine (layered) model� Used to model the interfacing of sub-systems.� Organises the system into a set of layers (or abstract machines) each of which provide
a set of services.� Supports the incremental development of sub-systems in different layers. When a
layer interface changes, only the adjacent layer is affected.� However, often artificial to structure systems in this way.
Modular decomposition styles� Styles of decomposing sub-systems into modules.� No rigid distinction between system organisation and modular decomposition.
Sub-systems and modules� A sub-system is a system in its own right whose operation is independent of the
services provided by other sub-systems.� A module is a system component that provides services to other components but
would not normally be considered as a separate system.� Modular decomposition� Another structural level where sub-systems are decomposed into modules.� Two modular decomposition models covered
� An object model where the system is decomposed into interactingobject;
� A pipeline or data-flow model where the system is decomposed intofunctional modules which transform inputs to outputs.
� If possible, decisions about concurrency should be delayed until modules areimplemented.
Object model
� Structure the system into a set of loosely coupled objects with well-defined interfaces.� Object-oriented decomposition is concerned with identifying object classes, their
attributes and operations.� When implemented, objects are created from these classes and some control model
Object model advantages� Objects are loosely coupled so their implementation can be modified without
affecting other objects.� The objects may reflect real-world entities.� OO implementation languages are widely used.� However, object interface changes may cause problems and complex entities may be
hard to represent as objects.
Function-oriented pipelining� Functional transformations process their inputs to produce outputs.� May be referred to as a pipe and filter model (as in UNIX shell).� Variants of this approach are very common. When transformations are sequential, this
is a batch sequential model which is extensively used in data processing systems.� Not really suitable for interactive systems.
Data Flow style• Has the goal of modifiability• Characterized by viewing the system as a series of transformations on successive
pieces of input data• Data enters the system and then flows through the components one at a time until they
are assigned to output or a data store• Batch sequential style
� The processing steps are independent components� Each step runs to completion before the next step begins
• Pipe-and-filter style� Emphasizes the incremental transformation of data by successive components� The filters incrementally transform the data (entering and exiting via streams)� The filters use little contextual information and retain no state between
instantiations� The pipes are stateless and simply exist to move data between filters
• Advantages� Has a simplistic design in the limited ways in which the components interact
with the environment� Consists of no more and no less than the construction of its parts� Simplifies reuse and maintenance� Is easily made into a parallel or distributed execution in order to enhance
system performance• Disadvantages
� Implicitly encourages a batch mentality so interactive applications are difficultto create in this style
� Ordering of filters can be difficult to maintain so the filters cannotcooperatively interact to solve a problem
� Exhibits poor performance• Filters typically force the least common denominator of data
representation (usually ASCII stream)• Filter may need unlimited buffers if they cannot start producing output
until they receive all of the input• Each filter operates as a separate process or procedure call, thus
incurring overhead in set-up and take-down time• Use this style when it makes sense to view your system as one that produces a well-
defined easily identified output� The output should be a direct result of sequentially transforming a well-
defined easily identified input in a time-independent fashion
• Has the goal of modifiability and scalability• Has been the dominant architecture since the start of software development• Main program and subroutine style
• Decomposes a program hierarchically into small pieces (i.e., modules)• Typically has a single thread of control that travels through various
components in the hierarchy• Remote procedure call style
• Consists of main program and subroutine style of system that is decomposedinto parts that are resident on computers connected via a network
• Strives to increase performance by distributing the computations and takingadvantage of multiple processors
• Incurs a finite communication time between subroutine call and response• Object-oriented or abstract data type system
� Emphasizes the bundling of data and how to manipulate and access data� Keeps the internal data representation hidden and allows access to the object
only through provided operations� Permits inheritance and polymorphism
• Layered system� Assigns components to layers in order to control inter-component interaction� Only allows a layer to communicate with its immediate neighbor� Assigns core functionality such as hardware interfacing or system kernel
operations to the lowest layer� Builds each successive layer on its predecessor, hiding the lower layer and
providing services for the upper layer� Is compromised by layer bridging that skips one or more layers to improve
• Use this style when the order of computation is fixed, when interfaces are specific,and when components can make no useful progress while awaiting the results ofrequest to other components
8.Textbook:T1: Roger S. Pressman, “Software Engineering – A practitioner’s Approach”, SixthEdition, McGraw-Hill International Edition, 2005
• Open-closed principle� A module or component should be open for extension but closed for
modification� The designer should specify the component in a way that allows it to be
extended without the need to make internal code or design modifications to theexisting parts of the component
• Liskov substitution principle� Subclasses should be substitutable for their base classes� A component that uses a base class should continue to function properly if a
subclass of the base class is passed to the component instead• Dependency inversion principle
o Depend on abstractions (i.e., interfaces); do not depend on concretionso The more a component depends on other concrete components (rather
than on the interfaces) the more difficult it will be to extend� Interface segregation principle
o Many client-specific interfaces are better than one general purposeinterface
o For a server class, specialized interfaces should be created to servemajor categories of clients
o Only those operations that are relevant to a particular category ofclients should be specified in the interface