MELJUN CORTES Software Eng'g Chapter5
Upcoming SlideShare
Loading in...5
×
 

MELJUN CORTES Software Eng'g Chapter5

on

  • 337 views

MELJUN CORTES Software Eng'g Chapter5

MELJUN CORTES Software Eng'g Chapter5

Statistics

Views

Total Views
337
Views on SlideShare
337
Embed Views
0

Actions

Likes
0
Downloads
3
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

MELJUN CORTES Software Eng'g Chapter5 MELJUN CORTES Software Eng'g Chapter5 Presentation Transcript

  • M L UN P CORT S,M A,M A,B EJ . E B P SCS Software Engineering: A Practitioner’s Approach, 6/e Chapter 5 Design Engineering 1
  • Design Engineering Creativity rules - coming together of customer requirements, business needs, technical considerations Design Specs: representation of S/W, with details about S/W data structures, architecture, interfaces, components and deployment 2
  • Analysis Model => Design Model Co m p o n e n t - sc e n a r i o - b a se d f l o w- o r i e n t e d L e v e l D e sig n e l e me nt s e l e me nt s use-cases - text data flow diagrams use-case diagrams control-flow diagrams activity diagrams processing narratives swim lane diagrams In t e r f a c e D e sig n Analysis Model A r c h it e c t u r a l D e sig n c l a ss- b a se d be ha v i or a l e l e me nt s e l e me nt s class diagrams state diagrams analysis packages sequence diagrams CR models C D a t a / Cla ss D e sig n collaboration diagrams Design Model 3 View slide
  • Generic Task Set Design data structures, or data objects and their attributes as appropriate to the information domain model Using the analysis model decide on the architectural style appropriate for the software Partition the analysis model into design subsystems and allocate these subsystem within the architecture:  Ensure that each subsystem is functionally cohesive  Design subsystem interfaces  Allocate analysis classes or functions to each subsystem 4 View slide
  • Generic Task Set Create a set of design classes or components:  Translate each analysis class description into a design class  Check each design class against quality criteria  Consider inheritance issues  Define methods and messages for each design class  Evaluate and select design patterns for each design class or a subsystem  Review the design classes and revise if needed Design interfaces to external systems or devices 5
  • Generic Task Set Design the user interface:  Review results of task analysis  Specify action sequences based on user scenarios  Create the behavioral model of the interface  Define interface objects and control mechanisms  Review the interface design and revise, if needed Conduct component-level design:  Specify all algorithms at a relatively low level of abstraction  Refine the interface of each component  Define component-level data structures  Review each component and correct any errors found Develop a deployment model 6
  • Design and Quality The design must implement all of the explicit requirements contained in the analysis model, and it must accommodate all of the implicit requirements desired by the customer. The design must be a readable, understandable guide for those who generate code and for those who test and subsequently support the software. The design should provide a complete picture of the software, addressing the data, functional, and behavioral domains from an implementation perspective. 7
  • Quality Guidelines A design should exhibit an architecture that  has been created using recognizable architectural styles or patterns,  is composed of components that exhibit good design characteristics and  can be implemented in an evolutionary fashion  For smaller systems, design can sometimes be developed linearly. A design should be modular; that is, the software should be logically partitioned into elements or subsystems A design should contain distinct representations of data, architecture, interfaces, and components. A design should lead to data structures that are appropriate for the classes to be implemented and are drawn from recognizable data patterns. A design should lead to components that exhibit independent functional characteristics. A design should lead to interfaces that reduce the complexity of connections between components and with the external environment. A design should be derived using a repeatable method that is driven by information obtained during software requirements analysis. A design should be represented using a notation that effectively communicates its meaning. 8
  • Quality Attributes Functionality - assessed by evaluating the feature set and capabilities of a program, generality of functions delivered, security of the overall system Usability - assessed by evaluating human factors (aesthetics, consistency, documentation) Reliability - evaluated by measuring MTBF and severity of failures, MTTR, ability to recover from failure, predictability Performance - evaluated by measuring processing speed, response time, resource consumption, throughput, efficiency, etc. Supportability - extensibility, adaptability, serviceability, testability, compatibility, configurability 9
  • Design Principles The design process should not suffer from ‘tunnel vision.’ The design should be traceable to the analysis model. The design should not reinvent the wheel. The design should “minimize the intellectual distance” [DAV95] between the software and the problem as it exists in the real world. The design should exhibit uniformity and integration. The design should be structured to accommodate change. The design should be structured to degrade gently, even when aberrant data, events, or operating conditions are encountered. Design is not coding, coding is not design. The design should be assessed for quality as it is being created, not after the fact. The design should be reviewed to minimize conceptual (semantic) errors. From Davis [DAV95] 10
  • Fundamental 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 Hiding — controlled interfaces Functional independence — single-minded function and low coupling Refinement — elaboration of detail for all abstractions Refactoring — a reorganization technique that simplifies the design 11
  • Data Abstraction door manufacturer model number type swing direction inserts lights type number weight opening mechanism implemented as a data structure 12
  • Procedural Abstraction open details of enter algorithm implemented with a "knowledge" of the object that is associated with enter 13
  • Architecture“The overall structure of the software and the ways inwhich that structure provides conceptual integrity for asystem.” [SHA95a]Structural properties. This aspect of the architectural design representationdefines the components of a system (e.g., modules, objects, filters) and themanner in which those components are packaged and interact with oneanother. For example, objects are packaged to encapsulate both data and theprocessing that manipulates the data and interact via the invocation of methodsExtra-functional properties. The architectural design description shouldaddress how the design architecture achieves requirements for performance,capacity, reliability, security, adaptability, and other system characteristics.Families of related systems. The architectural design should draw uponrepeatable patterns that are commonly encountered in the design of families ofsimilar systems. In essence, the design should have the ability to reusearchitectural building blocks. 14
  • Patterns (i.e. named “nuggets” of insight…)Design Pattern TemplatePattern name — describes the essence of the pattern in a short but expressivenameIntent — describes the pattern and what it doesAlso-known-as — lists any synonyms for the patternMotivation — provides an example of the problemApplicability — notes specific design situations in which the pattern is applicableStructure — describes the classes that are required to implement the patternParticipants — describes the responsibilities of the classes that are required toimplement the patternCollaborations — describes how the participants collaborate to carry out theirresponsibilitiesConsequences — describes the “design forces” that affect the pattern and thepotential trade-offs that must be considered when the pattern is implementedRelated patterns — cross-references related design patterns 15
  • Modular Designeasier to build, easier to change, easier to fix ... 16
  • Modularity: Trade-offsWhat is the "right" number of modulesfor a specific software design? module development cost cost of software module integration cost optimal number number of modules of modules 17
  • Information Hiding module • algorithm controlled interface • data structure • details of external interface • resource allocation policyclients "secret"a specific design decision 18
  • Why Information Hiding? reduces the likelihood of “side effects” limits the global impact of local design decisions emphasizes communication through controlled interfaces discourages the use of global data leads to encapsulation—an attribute of high quality design results in higher quality software 19
  • Stepwise Refinementopen walk to door; reach for knob; open door; repeat until door opens turn knob clockwise; walk through; if knob doesnt turn, then close door. take key out; find correct key; insert in lock; endif pull/push door move out of way; end repeat 20
  • Functional IndependenceCOHESION - the degree to w hich amodule performs one and only onefunction.COUPLING - the degree to w hich amodule is "connected" to othermodules in the system. 21
  • Sizing Modules: Two Views Whats How big inside?? is it?? MODULE 22
  • Refactoring Fowler [FOW99] defines refactoring in the following manner:  "Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code [design] yet improves its internal structure.” When software is refactored, the existing design is examined for:  redundancy  unused design elements  inefficient or unnecessary algorithms  poorly constructed or inappropriate data structures  or any other design failure that can be corrected to yield a better design. 23
  • OO Design Concepts Design classes  Entity classes  Boundary classes  Controller classes Inheritance—all responsibilities of a superclass is immediately inherited by all subclasses Messages—stimulate some behavior to occur in the receiving object Polymorphism—a characteristic that greatly reduces the effort required to extend the design 24
  • Design Classes Analysis classes are refined during design to become entity classes Boundary classes are developed during design to create the interface (e.g., interactive screen or printed reports) that the user sees and interacts with as the software is used.  Boundary classes are designed with the responsibility of managing the way entity objects are represented to users. Controller classes are designed to manage  the creation or update of entity objects;  the instantiation of boundary objects as they obtain information from entity objects;  complex communication between sets of objects;  validation of data communicated between objects or between the user and the application. 25
  • Inheritance Design options:  The class can be designed and built from scratch. That is, inheritance is not used.  The class hierarchy can be searched to determine if a class higher in the hierarchy (a superclass)contains most of the required attributes and operations. The new class inherits from the superclass and additions may then be added, as required.  The class hierarchy can be restructured so that the required attributes and operations can be inherited by the new class.  Characteristics of an existing class can be overridden and different versions of attributes or operations are implemented for the new class. 26
  • Messages:SenderObject message (<parameters>) :ReceiverObject 27
  • PolymorphismConventional approach … case of graphtype: if graphtype = linegraph then DrawLineGraph (data); if graphtype = piechart then DrawPieChart (data); if graphtype = histogram then DrawHisto (data); if graphtype = kiviat then DrawKiviat (data); end case;All of the graphs become subclasses of a general class called graph.Using a concept called overloading [TAY90], each subclass definesan operation called draw. An object can send a draw message toany one of the objects instantiated from any one of the subclasses.The object receiving the message will invoke its own draw operationto create the appropriate graph. graphtype draw 28
  • The Design Modelhigha na ly sis m ode l class diagrams analysis packages use-cases - t ext class diagrams Requirement s: CRC models use-case diagrams const raint s analysis packages collaborat ion diagrams act ivit y diagrams CRC models int eroperabilit y dat a f low diagrams sw im lane diagrams collaborat ion diagrams t arget s and cont rol-f low diagrams collaborat ion diagrams dat a f low diagrams processing narrat ives st at e diagrams cont rol-f low diagrams conf igurat ion sequence diagrams processing narrat ives st at e diagrams sequence diagrams design class realizat ions subsyst ems collaborat ion diagrams t echnical int erf ace component diagrams design class realizat ions design design classes subsyst ems Navigat ion design act ivit y diagrams collaborat ion diagrams GUI design sequence diagrams component diagramsde sign m ode l design classes ref inement s t o: act ivit y diagrams ref inement s t o: sequence diagrams component diagrams design class realizat ions design classes subsyst ems act ivit y diagrams low collaborat ion diagrams sequence diagrams deployment diagrams archit ect ure int erface component -level deployment -level element s element s element s element s process dimension 29
  • Design Model Elements Data elements  Data model --> data structures  Data model --> database architecture Architectural elements  Application domain  Analysis classes, their relationships, collaborations and behaviors are transformed into design realizations  Patterns and “styles” (Chapter 10) Interface elements  the user interface (UI)  external interfaces to other systems, devices, networks or other producers or consumers of information  internal interfaces between various design components. components Component elements Deployment elements 30
  • Interface Elements MobilePhone WirelessPDA Cont rolPanelLCDdisplayLEDindicat orskeyPadCharact erist ics Key PadspeakerwirelessInt erf acereadKeySt 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 31
  • Component Elements SensorManagement Sensor 32
  • Deployment Elements Cont rol Panel CPI serv er Security homeownerAccess Personal comput er externalAccess Security Surveillance homeManagement communication Figure 9 .8 UML deploy m ent diagram for SafeHom e 33
  • Design Patterns The best designers in any field have an uncanny ability to see patterns that characterize a problem and corresponding patterns that can be combined to create a solution A description of a design pattern may also consider a set of design forces.  Design forces describe non-functional requirements (e.g., ease of maintainability, portability) associated the software for which the pattern is to be applied. The pattern characteristics (classes, responsibilities, and collaborations) indicate the attributes of the design that may be adjusted to enable the pattern to accommodate a variety of problems. 34
  • Frameworks A framework is not an architectural pattern, but rather a skeleton with a collection of “plug points” (also called hooks and slots) that enable it to be adapted to a specific problem domain. Gamma et al note that:  Design patterns are more abstract than frameworks.  Design patterns are smaller architectural elements than frameworks  Design patterns are less specialized than frameworks 35