Your SlideShare is downloading. ×
Software engg. pressman_ch-9
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Software engg. pressman_ch-9

453
views

Published on

Published in: Technology

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
453
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
27
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Chapt er 9 Design Engineer ing Software Engineering: A Practitioner’s Approach, 6th edition by Roger S. Pressman 1
  • 2. Translating Analysis Model into Design Model Chapt er 9 Design Engineer ing Software Engineering: A Practitioner’s Approach, 6th edition by Roger S. Pressman 2
  • 3. Translating Analysis Model into Design Model Data / Class design: transforms analysis-class models into design class realizations and the requisite data structures required to implement the software. Architectural Design: defines the relationship between major structural elements of the software, the architectural styles and design patterns that can be used to achieve the requirements defined for the system and the constraints that affect the way in which architectural can be implemented. 3
  • 4. Translating Analysis Model into Design Model Interface Design: describes how the software communicates with systems that interoperated with it, and with humans who use it. Component level Design: transforms structural elements of the software architecture into procedural description of software components. 4
  • 5. Design Process and Design Quality Characteristics that serve as a guide for the evaluation of a good design. 1. 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 customers. 2. The design must be readable, understandable guide for those who generate code and for those who test and subsequently support the software. 3. The design should provide a complete picture of the software, addressing the data, functional, and behavioral domains from an implementation perspective. 5
  • 6. Characteristics of a good design exhibit an architecture that is : A design should created using recognizable architectural styles or patterns composed of components that exhibits good design characteristics can be implemented in an evolutionary fashion , thereby facilitating implementation and testing. A design should be modular. A design should contain distinct representations of data, architecture, interfaces and components. A design should lead to data structures that are appropriate for the classes to be implemented and are drawn from recognizable data pattern. 6
  • 7. Characteristics of a good design A design should lead to components that exhibit independent functional characteristics. A design should lead to interfaces that reduce the complexity of connections between components and with the external environment. A design should be derived using a repeatable method that is driven by information obtained during software requirements analysis. A design should be represented using a notation that effectively communicates its meaning. 7
  • 8. Quality Attributes FURPS quality attributes represent a target for all software design. Functionality: assessed by evaluating the feature set and capabilities of the program, functions that are delivered, and the security of the overall system. Usability: assessed by considering human factors, overall aesthics, consistency and documentation. Reliability: evaluated by measuring the frequency and severity of failure, the accuracy of output results, the mean-time-to-failure(MTTF), the ability to recover from failure, and the predictability of the 8 program.
  • 9. Quality Attributes contd… Performance: measured by processing speed, response time, resource consumption, throughput, and efficiency. Supportability: combines the ability to extend the program (extensibility), adaptability, serviceability--these three attributes represent a more common term, maintainability. In addition testability, compatibility, configurability, ease with which a system can be installed, and the ease with which problems can be localized. 9
  • 10. Design Concepts abstraction — data, procedure, control architecture — the overall structure of the software patterns — “conveys the essence” of a proven design solution modularity — compartmentalization of data and function information hiding — controlled interfaces functional independence — high cohesion and low coupling refinement — elaboration of detail for all abstractions refactoring — improve design without effecting behavior 10
  • 11. Design Concepts cont….... we consider a modular solution to Abstraction: when any problem, many levels of abstraction can be posed. (i) highest level – stated in broad terms (ii) lowest level – more detailed description is provided. As we move through different levels of abstraction, we work to create procedural and data abstractions. 1) Procedural abstraction refers to a sequence of instructions that have a specific and limited function. 2) Data abstraction is a named collection of data that 11 describes a data object.
  • 12. Data Abstraction door Manufacturer Model no Type Weight Swing direction Opening mechanism Implemented as a data structure 12
  • 13. Procedural Abstraction open Details of enter algorithm Implemented with a “knowledge” of the object that is associated with 13 enter
  • 14. Architecture & Patterns Architecture is the overall structure or organization of program components(modules), the manner in which these components interact, and the structure of data that are used by the components. A design pattern describes a design structure that solves a particular design problem within a specific context and amid “forces” that may have an impact on the manner in which the pattern is applied and used. 14
  • 15. Modularity  Software is divided into separately named components, called modules, that are integrated to satisfy problem requirements. When we sub divide software, the effort required to develop it will become small. However, as the number of modules grows, the effort (cost) associated with integrating the modules also grows. Why modularize a design ? -development can be more easily planned, -software increments can be defined and delivered, -changes can be more easily accommodated, testing and debugging can be conducted more efficiently -long term maintenance can be conducted without serious side effects. 15
  • 16. Modular Design easier to build, easier to change, easier to fix ... easier to build, easier to change, easier to fix ... 16
  • 17. Modular it y: Tr ade-of f s What is the "right" number of modules for a specific software design? module development cost cost of software module integration cost optimal number of modules number of modules 17
  • 18. Information Hiding The principle of information hiding suggests that modules be characterized by design decisions that (each) hides from all others. In other words, modules should be specified and designed so that information (algorithm and data) contained within a module is inaccessible to other modules that have no need for such information. In short abstraction helps to define the procedural entities that make up the software. Hiding defines and enforces access constraints to both procedural detail within a module and any local data structure used by the module. 18
  • 19. Functional Independence Functional independence is achieved by developing modules with single-minded function and with a dislike to excessive interaction with other modules. In another way we can say that we want to design software so that each module addresses a specific sub function of requirements and has a simple interface when viewed from other parts of the program structure. 19
  • 20. Functional Independence contd… Independence is assessed using two qualitative criteria: cohesion and coupling. Cohesion is a natural extension of the information hiding concept, wherein cohesive module performs a single task, requiring little interaction with other components in other parts of the program. Coupling is an indication of interconnection among modules in a software structure. Coupling depends on the interface complexity between modules, the point at which entry or reference is made of a module, and what data pass across the interface. In software design, we strive for lowest possible coupling. 20
  • 21. Funct ional I ndependence to which a COHESION - the degree module performs one and only one function. COUPLING - the degree to which a module is "connected" to other modules in the system. 21
  • 22. Refinement Refinement is actually a process of elaboration. Statement describes function or information conceptually but provides no information about the internal workings of the function or the internal structure of the data. Refinement causes the designer to elaborate on the original statement, providing more and more detail as each successive refinement (elaboration) occurs. Abstraction and refinement are complementary concepts. Abstraction enables a designer to specify procedure and data and yet suppress low-level details. Refinement helps the 22 designer to reveal low-level details as design progresses.
  • 23. St epwise Ref inement open walk to door; reach for knob; open door; walk through; close door. repeat until door opens turn knob clockwise; if knob doesn't turn, then take key out; find correct key; insert in lock; endif pull/push door move out of way; end repeat 23
  • 24. Refactoring Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code (design) yet improves its internal structure. When software is refactored, the existing design is examined for redundancy, unused design elements, inefficient or unnecessary algorithms, poorly constructed or in appropriate data structure, or any other design failure that can be corrected to yield a better design. 24
  • 25. Design Classes Five different types of design classes, each representing a different layer of the design architecture are suggested. User interface classes – define abstractions necessary for Human Computer Interface. Business domain classes – refinements of analysis classes. Process classes – lower-level business abstractions that manage business domain classes. Persistent classes – data stores (databases) that persist beyond execution of the software. System classes – management and control functions that enable the system to operate and communicate within its computing environment and with the outside world. 25
  • 26. Guide lines for well-formed design class: Following are the four characteristics of a well-formed design class: 1. Complete and Sufficient: class should be complete and sufficient that is encapsulation of reasonable attributes and methods. 2. Primitiveness: each method should be focused on one thing. 3. High cohesion – class should be focused on one kind of thing. 4. Low coupling – should have only limited knowledge of classes in other subsystems. 26
  • 27. The Design Model high a na ly sis m ode l class diagrams analysis packages CRC models collaborat ion diagrams dat a f low diagrams cont rol-f low diagrams processing narrat ives design class realizat ions subsyst ems collaborat ion diagrams use-cases - t ext use-case diagrams act ivit y diagrams sw im lane diagrams collaborat ion diagrams st at e diagrams sequence diagrams class diagrams analysis packages CRC models collaborat ion diagrams dat a f low diagrams cont rol-f low diagrams processing narrat ives st at e diagrams sequence diagrams t echnical int erf ace design Navigat ion design GUI design component diagrams design classes act ivit y diagrams sequence diagrams de sign m ode l ref inement s t o: low ref inement s t o: design class realizat ions subsyst ems collaborat ion diagrams archit ect ure element s component diagrams design classes act ivit y diagrams sequence diagrams int erface element s component -level element s Requirement s: const raint s int eroperabilit y t arget s and conf igurat ion design class realizat ions subsyst ems collaborat ion diagrams component diagrams design classes act ivit y diagrams sequence diagrams deployment diagrams deployment -level element s process dimension 27
  • 28. Design Model Elements Data elements Architectural level  databases and files Component level  data structures & algorithms Architectural elements An architectural model is derived from: Application domain Analysis model Available styles and patterns Interface elements There are three parts to the interface design element: The user interface (UI) Interfaces to external systems Interfaces to components within the application Component elements Deployment elements 28
  • 29. Design Model Elements MobilePhone WirelessPDA Cont rolPanel LCDdisplay LEDindicat ors keyPadCharact erist ics speaker wirelessInt erf ace Key Pad readKeySt roke() decodeKey () displaySt at us() light LEDs() sendCont rolMsg() < < int erfac e> > Key Pad readKeyst roke() decodeKey() Figure 9 .6 UML int erfac e represent at ion for Co n t r o lPa n e l 29
  • 30. I nt er f ace Element s MobilePhone WirelessPDA Cont rolPanel LCDdisplay LEDindicat ors keyPadCharact erist ics speaker wirelessInt erf ace Key Pad readKeySt roke() decodeKey () displaySt at us() light LEDs() sendCont rolMsg() < < int erfac e> > Key Pad readKeyst roke() decodeKey() Figure 9 .6 UML int erfac e represent at ion for Co n t r o lPa n e l 30
  • 31. Component Element s SensorManagement Sensor 31
  • 32. Deployment Diagr am 32