Your SlideShare is downloading. ×
0
L01web 2x2
L01web 2x2
L01web 2x2
L01web 2x2
L01web 2x2
L01web 2x2
L01web 2x2
L01web 2x2
L01web 2x2
L01web 2x2
L01web 2x2
L01web 2x2
L01web 2x2
L01web 2x2
L01web 2x2
L01web 2x2
L01web 2x2
L01web 2x2
L01web 2x2
L01web 2x2
L01web 2x2
L01web 2x2
L01web 2x2
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

L01web 2x2

116

Published on

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

  • Be the first to like this

No Downloads
Views
Total Views
116
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
1
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. Software Design Motivation MethodologiesComp 6471 Comp 6471 COMP 6471/4 NN Steven Winikoff …with proper design, the features come cheaply. This approach is arduous, but smw@alcor.concordia.ca continues to succeed. H-966-2 - Dennis Ritchie 514-848-2424, ext. 7619 Page 7 What This Course is About Software Engineering ca. 1968: Reasons for the software crisis were determined.Comp 6471 simple questions: Software development should be treated as an engineering activity and not as an ad-hoc activity => software development should be a systematical activity. What should go into a given piece of software? Definition provided by the IEEE: Software Engineering is the systematic approach to development , maintenance, organization of software How do you put it there? systems. Starting point of the software crisis. ...with complex answers Acknowledgement: These slides are based on work originally created by Dr. Juergen Rilling, CSE, Concordia Comp6471 Software Design Methodologies
  • 2. Page 8 Page 9 Goals of Software Engineering Software Life Cycle The phases of a software development cycle. Improve the productivity of the programming/development process  Analysis: Software Engineering Improve the comprehension of the developed software system  Specification Improve the maintainability of the systems 70 Improve the quality of the software system (software product)  Design 60 50 Improve the “quality” of the software system.  Implementation 40 Without SE - Reliability Effort  Testing 30 Applying SE - Efficiency (Speed, resource usage)  Delivery/Maintenance 20 - User-friendly (user acceptance) 10 0 General goal: n n gn g s io t io in si Produce software which is useful for people si at st y ta De al Te f ic en An i ec em Sp pl Im Software Life Cycle Phase Comp6471 Software Design Methodologies Comp6471 Software Design MethodologiesPage 10 Page 11 Software Life Cycle Goals of Software Engineering Products: External deliverables, internal products; software products: final code, test drivers  Feasibility study – WHY? Cost benefit analysis (is Paper documents: external: user manual, installation guide; it worth doing the project) Internal: requirements document, specification document,  Requirements analysis + specification: WHAT? design document, test plan What should the software do, produce a document.  Design - How? How should the software do it. Architectural design (overall structures + organization Processes: How the software is created, how its quality is evaluated and of objects/modules, choice of data structures, etc. ensured  Coding/Implementation: Realize ! components. Tools: CASE tools, editors, project management tools Code modules, prodcuts: software,  Testing: Realize ! Test individual modules, test People: Technical, social and managerial skills whether modules work together, test system as a whole, document test results. Principles Providing permanency, guidelines and maturity in the software  Delivery and maintenance: Evolve! development process. Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
  • 3. Page 12 Page 13 Skills of a Software Engineer Skills of a Software Engineer  Programming: Design  data structures and algorithms – be familiar with several approaches  programming languages – be flexible and open to different application domains  tools: compilers, debuggers, editors – be able to shift between several level of abstraction  Communication: – application domain jargon  spoken, written, presentations  teamwork – requirements and specification: declarative model  with external people (customers) – architectural design, high-level operational model – detailed coding Comp6471 Software Design Methodologies Comp6471 Software Design MethodologiesPage 14 Page 15 Software Lifecycle Models A lifecycle model provides a fixed generic framework that can be tailored to a specific project. Project specific parameters will include: Definition.  size (person-years), A (software/system) lifecycle model is a  budget, description of the sequence of activities carried  duration. out in a software engineering project, and the relative order of these activities. project plan = lifecycle model + project parameters Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
  • 4. Page 16 Page 17 There are many different lifecycle models to choose By changing the lifecycle model, we can from, e.g: improve and/or trade off:  waterfall,  code-and-fix  development speed (time to market)  spiral  product quality  rapid prototyping  unified process (UP)  project visibility  agile methods, extreme programming (XP)  administrative overhead  COTS …  risk exposure  customer relations, etc, etc. but many are minor variations on a smaller number of basic models. Comp6471 Software Design Methodologies Comp6471 Software Design MethodologiesPage 18 Page 19 Normally, a lifecycle model covers the entire Note that we can sometimes combine lifetime of a product. lifecycle models e.g. waterfall inside evolutionary – onboard From the birth of an idea to the final shuttle software deinstallation of the last release We can also change lifecycle model between i.e. The three main phases: releases as a product matures,  design,  build, e.g. rapid prototyping → waterfall  maintain. Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
  • 5. Page 20 Page 21 phase User Requirements output User Requirements Document The Waterfall Model Software Requirements Software Requirements Document • Classic lifecycle model – widely known, understood and (commonly?) used. Architecture Design Architectural Design Document • In some respect, waterfall is the "common ”Swimming sense" approach upstream” Detailed design & Coding Detailed Design (Introduced by Royce 1970) & Code The Waterfall Testing Lifecycle Workflow Delivery Time Comp6471 Software Design Methodologies Comp6471 Software Design MethodologiesPage 22 Page 23 Advantages Disadvantages I 1. Easy to understand and implement. 2. Widely used and known (in theory!) ● Idealized, doesn’t match reality well. 3. Reinforces good habits: define-before-design, ● Doesn’t reflect iterative nature of exploratory design-before-code development. 4. Identifies deliverables and milestones ● Unrealistic to expect accurate requirements so early 5. Document driven, URD, SRD, … etc. Published in project documentation standards, e.g. PSS-05. ● Software is delivered late in project, delays 6. Works well on mature products and weak teams. discovery of serious errors. Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
  • 6. Page 24 Page 25 Disadvantages II Code-and-Fix ● Difficult to integrate risk management This model starts with an informal general ● Difficult and expensive to make changes to product idea and just develops code until a documents, ”swimming upstream”. product is ”ready” (or money or time runs out). ● Significant administrative overhead, costly for Work is in random order. small teams and projects. Corresponds with no plan! Comp6471 Software Design Methodologies Comp6471 Software Design MethodologiesPage 26 Page 27 Advantages Disadvantages ● No administrative overhead 1. Dangerous! ● Signs of progress (code) early. ● No visibility/control ● Low expertise, anyone can use it! ● No resource planning ● Useful for small “proof of concept” projects, ● No deadlines ● Mistakes hard to detect/correct e.g. as part of risk reduction. 2. Impossible for large projects, communication breakdown, chaos. Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
  • 7. Page 28 Page 29 This loop approach gives rise to structured Spiral Model iterative lifecycle models. Since end-user requirements are hard to obtain/define, it is natural to develop software In 1988 Boehm developed the spiral model as in an experimental way: e.g. an iterative model which includes risk analysis and risk management. 1. Build some software 2. See if it meets customer requirements Key idea: on each iteration identify and solve 3. If no goto 1 else stop. the sub-problems with the highest risk. Comp6471 Software Design Methodologies Comp6471 Software Design MethodologiesPage 30 Page 31 Cumulative cost Determine objectives, Evaluate alternatives, alternatives & constraints Identify & resolve risks Each cycle follows a waterfall model by: 1. Determining objectives 2. Specifying constraints Prototypes Operational Review & Start P1 P2 P3 Prototype 3. Generating alternatives commitment Requirements Concept Design, 4. Identifying risks plan Detailed design Of Operation Development Validation 5. Resolving risks & Verification plan Requirements 6. Developing next-level product validation Coding Integration & 7. Planning next cycle Test plan Unit & Integration Testing End Acceptance Plan next phase Testing Develop & verify next-level product Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
  • 8. Page 32 Page 33 Advantages Disadvantages 1. Realism: the model accurately reflects the  Needs technical expertise in risk analysis to really iterative nature of software development on work projects with unclear requirements  Model is poorly understood by non-technical 2. Flexible: incorporates the advantages of the management, hence not so widely used waterfall and rapid prototyping methods  Complicated model, needs competent professional management. High administrative overhead. 3. Comprehensive model decreases risk 4. Good project visibility. Comp6471 Software Design Methodologies Comp6471 Software Design MethodologiesPage 34 Page 35 Requirements Capture Rapid Prototyping Iterate Quick Design Key idea: Customers are non-technical and usually don’t know what they want/can have. Build Prototype Rapid prototyping emphasises requirements Customer Evaluation of analysis and validation, also called: Prototype  customer oriented development,  evolutionary prototyping The Rapid Engineer Final Prototype Workflow Product Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
  • 9. Page 36 Page 37 Advantages Disadvantages I 1. Reduces risk of incorrect user requirements 1. An unstable/badly implemented prototype 2. Good where requirements are often becomes the final product. changing/uncommitted 2. Requires extensive customer collaboration 3. Regular visible progress aids management – Costs customers money 4. Supports early product marketing – Needs committed customers – Difficult to finish if customer withdraws – May be too customer specific, no broad market Comp6471 Software Design Methodologies Comp6471 Software Design MethodologiesPage 38 Page 39 Disadvantages II Agile (XP) Manifesto 3. Difficult to know how long project will last XP = Extreme Programming emphasizes: 4. Easy to fall back into code-and-fix without  Individuals and interactions proper requirements analysis, design, – Over processes and tools customer evaluation and feedback.  Working software – Over documentation  Customer collaboration – Over contract negotiation  Responding to change – Over following a plan Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
  • 10. Page 40 Page 41 Agile Principles (Summary) XP Practices (Summary)  Continuous delivery of software  Programming in pairs  Continuous collaboration with customer  Test driven development  Continuous update according to changes  Continuous planning, change , delivery  Value participants and their interaction  Shared project metaphors, coding standards and  Simplicity in code, satisfy the spec ownership of code  No overtime! (Yeah right!) Comp6471 Software Design Methodologies Comp6471 Software Design MethodologiesPage 42 Page 43 Advantages Disadvantages  Lightweight methods suit small-medium size  Difficult to scale up to large projects where projects documentation is essential  Produces good team cohesion  Needs experience and skill if not to degenerate  Emphasizes final product into code-and-fix  Iterative  Programming pairs is costly  Test-based approach to requirements and quality  Test case construction is a difficult and specialized assurance skill. Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
  • 11. Page 44 Page 45 Advantages COTS  Fast, cheap solution  May give all the basic functionality  COTS = Commercial Off-The-Shelf software  Well defined project, easy to run  Engineer together a solution from existing commercial software packages using minimal Disadvantages software "glue".  Limited functionality  E.g. using databases, spread sheets, word  Licensing problems, freeware, shareware, etc. proccessors, graphics software, web browsers,  License fees, maintainance fees, upgrade etc. compatibility problems Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies Page 47 Unified Process (UP)  Booch, Jacobson, Rumbaugh 1999. Comp 6471 Iterative Development and the  Lifetime of a software product in cycles: Unified Process  – Birth, childhood, adulthood, old-age, death. Product maturity stages  Each cycle has phases, culminating in a new release (c.f. Spiral model) Acknowledgement: These slides for the Iterative Development process were originally created by Dr. Constantinos Constantinides, CSE, Concordia Comp6471 Software Design Methodologies
  • 12. Page 48 Page 49 Iterative Development Iterative Development [iteration N] Requirements – Analysis - Design- Implementation - Testing  The iterative lifecycle is based on the successive enlargement and refinement of a system though multiple iterations with feedback and adaptation. [iteration N+1]  The system grows incrementally over time, Requirements – Analysis - Design- Implementation - Testing iteration by iteration.  The system may not be eligible for production Feedback from iteration N leads to refinement and adaptation of the The system grows deployment until after many iterations. requirements and design in iteration incrementally. N+1. Comp6471 Software Design Methodologies Comp6471 Software Design MethodologiesPage 50 Page 51 Iterative Development Embracing Change  The output of an iteration is not an  Stakeholders usually have changing experimental prototype but a production requirements. subset of the final system.  Each iteration involves choosing a small  Each iteration tackles new requirements and subset of the requirements and quickly incrementally extends the system. design, implement and testing them.  An iteration may occasionally revisit existing  This leads to rapid feedback, and an software and improve it. opportunity to modify or adapt understanding of the requirements or design. Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
  • 13. Page 52 Page 53 Iteration Length and Timeboxing Phases of the Unified Process Inception Elaboration Construction Transition time  The UP recommends short iteration lengths to allow for rapid feedback and adaptation. A UP project organizes the work and iterations  Long iterations increase project risk. across four major phases:  Iterations are fixed in length (timeboxed).If – Inception - Define the scope of project. meeting deadline seems to be difficult, then – Elaboration - Plan project, specify features, remove tasks or requirements from the baseline architecture. iteration and include them in a future iteration.  The UP recommends that an iteration should – Construction - Build the product be between two and six weeks in duration. – Transition - Transition the product into end user community Comp6471 Software Design Methodologies Comp6471 Software Design MethodologiesPage 54 Page 55 Iterations and Milestones The UP Disciplines Phases Process Disciplines Inception Elaboration Construction Transition Inception Elaboration Construction Transition Business Modeling Requirements Preliminary Iter. #1 Iter. #2 Iteration Analysis & Design Implementation Milestone Release Final production Test release Deployment  Each phase and iteration has some risk mitigation focus, and Supporting Disciplines concludes with a well-defined milestone. Configuration Mgmt  The milestone review provides a point in time to assess how Management well key goals have been met and whether the project needs to be restructured in any way to proceed. Environment  The end of each iteration is a minor release, a stable executable Preliminary Iteration(s) Iter. #1 Iter. #2 Iter. #n Iter. Iter. #n+1 #n+2 Iter. #m Iter. #m+1 subset of the final product. Iterations Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
  • 14. Page 56 Page 57 The UP Disciplines In an iteration you walk through all The UP Disciplines Focus of this course. Phases disciplines. Phases Process Disciplines Inception Elaboration Construction Transition Process Disciplines Inception Elaboration Construction Transition Business Modeling Business Modeling Requirements Requirements Analysis & Design Analysis & Design Implementation Implementation Test Test Deployment Deployment Supporting Disciplines Supporting Disciplines Configuration Mgmt Configuration Mgmt Management Management Environment Environment Preliminary Iter. Iter. Iter. Iter. Iter. Iter. Iter. Preliminary Iter. Iter. Iter. Iter. Iter. Iter. Iter. Iteration(s) #1 #2 #n #n+1 #n+2 #m #m+1 Iteration(s) #1 #2 #n #n+1 #n+2 #m #m+1 Iterations Iterations Comp6471 Software Design Methodologies Comp6471 Software Design MethodologiesPage 58 Page 59 Advantages of an Disciplines and Phases Iterative Process  Although an iteration includes work in most  Reduce risks disciplines, the relative effort and emphasis change – Risks are identified early, progress is easier to see. over time.  Get a robust architecture – Early iterations tend to apply greater emphasis to – Architecture can be assessed and improve early. requirements and design, and later ones less so.  Handle evolving requirements – Figure illustrations are suggestive, not literal. – Users provide feedback to operational systems. – Responding to feedback is an incremental change.  Note that activities and artifacts are optional (except  Allow for changes code!) – System can adapt to problems – Developers select those artifacts that address their particular needs.  Attain early learning – Everyone obtains an understanding of the different workflows early on. Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
  • 15. Page 60 Page 61 Unified Process Product UML class diagram! Management Software Lifecycle Use Case Model Environment * * releases specified by by ed Workflow Cycle deployed by lis a Analysis Model re Requirements im Inception ple 4 me Design Design Model n te Phase Elaboration db Deployment Model verified by y Implementation Construction * Implementation Model Assessment Iteration Transition All models are interdepedent but this only shown for use Test Model Deployment * case model Artifact Comp6471 Software Design Methodologies Comp6471 Software Design MethodologiesPage 62 Page 63 What artifacts may start in Inception inception?  A number of questions need to be explored:  Vision and business case – What is the vision and business case for this project? – Describes high-level goals and constraints. – Is it feasible?  Use Case model – Buy and/or build? – Describes functional requirements and related non-functional – Rough estimate of cost. requirements. – Should we proceed or stop?  Supplementary specification – Describes other requirements  Glossary  The intent is to establish some initial common vision – Key domain terminology for the objectives of the project, determine if it is feasible and decide if it is worth some serious  Risk list and Risk Management Plan – Describes business, technical, resource and schedule risks investigation in elaboration. and ideas for their mitigation or response. Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
  • 16. Page 64 Page 65 What artifacts may start in Requirements Engineering: inception? An Overview  Prototypes and proof-of-concepts  Basic goal: To understand the problem as  Iteration plan perceived by the user. – Describes what to do in the first elaboration iteration  Phase Plan & Software development Plan  Activities of RE are problem oriented. – Guess for elaboration phase duration. Tools, people, – Focus on what, not how education and other resources. – Don’t cloud the RD with unnecessary detail  Development Case – Don’t pre-constrain design. – Description of the customized UP steps and artifacts for this project.  After RE is done, do software design:  Artifacts will be partially completed in this phase and – solution oriented will be refined in later iterations. – how to implement the what Comp6471 Software Design Methodologies Comp6471 Software Design MethodologiesPage 66 Page 67 Requirements Engineering: Requirements Engineering An Overview The process of determining and establishing  Key to RE is good communication between the precise expectations of the customer customer and developers. about the proposed software system.  Work from Requirements Document as guide. Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
  • 17. Page 68 Page 69 The Two Kinds of Requirements The Purpose of RE  Raw user requirements are often:  Functional: The precise tasks or functions – vague the system is to perform. – contradictory – e.g., details of a flight reservation system – impractical or impossible to implement – overly concrete  Non-functional: Usually, a constraint of – just plain wrong some kind on the system or its construction  The purpose of RE is to get a usable set of – e.g., expected performance and memory requirements from which the system may be requirements, process model used, designed and implemented, with minimal implementation language and platform, surprises. compatibility with other tools, deadlines, ... Comp6471 Software Design Methodologies Comp6471 Software Design MethodologiesPage 70 Page 71 Requirements Analysis leads to The RE Process The Requirements Document Requirements produces Definition  The official statement of what is required of System Requirements the system developers. Models Specification – Includes system models, requirements definition, and requirements specification. Requirements – Not a design document. Software Definition Specification – States functional and non-functional requirements. included in Requirements Specification  Serves as a reference document for maintenance. Requirements Software Document Specification Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
  • 18. Page 72 Page 73 Requirements Document The Requirements Document “Requirements” Should State ...  Foreseen problems: – “won’t support Win-3.x apps”  Should be easy to change as requirements  Expected evolution: evolve. – “will port to MacOS in next version”  Must be kept up-to-date as system changes.  Response to unexpected events/usage: – “if input data in old format, will auto-convert” Comp6471 Software Design Methodologies Comp6471 Software Design MethodologiesPage 74 Page 75 Requirements Document A Story ... Structure Dear Mr. Architect,  Introduction (describe need for system)  Functional Requirements Please design and build me a house. I am not quite sure of what I need, so you should use your discretion.  Non-Functional Requirements  System Evolution (describe anticipated changes) My house should have between two and forty-five bedrooms. Just make sure the plans are such that bedrooms can be easily  Glossary (technical and/or new jargon) added or deleted. When you bring the blueprints to me, I will  Appendices make the final decision of what I want. Also bring me the cost breakdown for each configuration so that I can arbitrarily pick  Index one. Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
  • 19. Page 76 Page 77 A Story … (Cont’d) A Story … (Cont’d) Please take care that modern design practices and the latest Keep in mind that the house I ultimately choose must cost materials are used in construction of the house, as I want it to be a less than the one I am currently living in. Make sure, showplace for the most up-to-date ideas and methods. Be alerted, however, that you correct all the deficiencies that exist in my however, that kitchen should be designed to accommodate, among current house (the floor of my kitchen vibrates when I walk other things, my 1952 Gibson refrigerator. across it, and the walls don’t have nearly enough insulation in them). To insure that you are building the correct house for our entire family, make certain that you contact each of our children, and As you design, also keep in mind that I want to keep yearly also our in-laws. My mother-in-law will have very strong feelings maintenance costs as low as possible. This should mean the about how the house should be designed, since she visits us at incorporation of extra-cost features like aluminum, vinyl, or least once a year. Make sure that you weigh all of these options carefully and come to the right decision. I, however, retain the composite siding. (If you choose not to specify aluminum, be right to overrule any choices that you make. prepared to explain your decision in detail.) Comp6471 Software Design Methodologies Comp6471 Software Design MethodologiesPage 78 Page 79 A Story … (Cont’d) A Story … (Cont’d) While you are designing this house specifically for me, keep in mind that sooner or later I will have to sell it to someone else. It therefore Please dont bother me with small details right now. Your job is to should have appeal to a wide variety of potential buyers. Please develop the overall plans for the house: get the big picture. At this make sure before you finalize the plans that there is a consensus of time, for example, it is not appropriate to be choosing the color of the population in my area that they like the features this house has. the carpet. However, keep in mind that my wife likes blue. I advise you to run up and look at my neighbors house he Also, do not worry at this time about acquiring the resources to constructed last year. We like it a great deal. It has many features build the house itself. Your first priority is to develop detailed that we would also like in our new home, particularly the 75-foot plans and specifications. Once I approve these plans, however, I swimming pool. With careful engineering, I believe that you can would expect the house to be under roof within 48 hours. design this into our new house without impacting the final cost. Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
  • 20. Page 80 Page 81 A Story … (Cont’d) A Story … (Cont’d) Please prepare a complete set of blueprints. It is not necessary at P.S. My wife has just told me that she disagrees with many on the this time to do the real design, since they will be used only for instructions I’ve given you in this letter. As architect it is construction bids. Be advised, however, that you will be held your responsibility to resolve these issues. I have tried in the accountable for any increase of construction costs as a result of past and have been unable to accomplish this. If you can’t handle later design changes. this, I will have to find a new architect. You must be thrilled to be working on as an interesting project as P.P.S. Perhaps what I need is not a house at all, but a travel trailer. this! To be able to use the latest techniques and materials and to be Please advise me as soon as possible if that is the case. given such freedom in your designs is something that cant happen very often. Contact me as soon as possible with your complete ideas and plans. (originally posted to the rec.humor.funny newsgroup in January 1993 -- but some things never change!) Comp6471 Software Design Methodologies Comp6471 Software Design MethodologiesPage 82 Page 83 RE Summary RE Summary (Cont’d)  RE focuses on determining what the  The customer often doesn’t have good grasp customer wants, and not how it will be of what he wants. implemented.  Errors made at the requirements stage are  RE is hard to get correct; it requires good very expensive to fix later. communication skills. – You might well implement the stated requirements  Requirements may change over time. correctly, but it won’t be the system the customer really wants.  RE requires iteration. Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
  • 21. Page 84 Page 85 Object-Oriented Analysis Back to Software Design ...  An investigation of the problem (rather than how a solution is defined)  During OO analysis, there is an emphasis on finding and describing the objects (or concepts) in the problem domain. – For example, concepts in a Library Information System include Book and Library. Comp6471 Software Design Methodologies Comp6471 Software Design MethodologiesPage 86 Page 87 Software architecture Subsystem decomposition High-Level Top-Down vs Bottom-Up Design (abstract) Subsystem dependencies design  Top-down Design: Subsystem – Start with a coarsely-grained view of system, and interfaces repeatedly refine components until you have module or class concrete sub-components. decomposition module or class dependencies  Bottom-up Design: – Start with existing components and “glue” them module or class interfaces Low-Level together to get what you want. (detailed) Data structures design Algorithms Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
  • 22. Page 88 Page 89 Top-Down vs Bottom-Up Design (Cont’d) Design Quality Software design “quality”, as with other ideas  Top-down is the “ideal” of most design on quality, is an elusive concept: it depends methods, but it’s rarely followed absolutely: on priorities of your company and the – some branches of development are expanded customers: before others are even started – fastest to implement – doesn’t adequately account for reuse of existing – easiest to implement components: – easiest to maintain, “evolve”, port  COTS products, libraries, previous versions of the same system. – most efficient/reliable/robust end-product. Comp6471 Software Design Methodologies Comp6471 Software Design MethodologiesPage 90 Page 91 Discussion Object-Oriented Design What does “quality” mean to:  Emphasizes a conceptual solution that fulfils – IBM? the requirements. – Microsoft?  Need to define software objects and how they – Mozilla? collaborate to fulfill the requirements. – FAA? – For example, in the Library Information System, a Book software object may have a title attribute and – IRS? a getChapter method. – Intel?  Designs are implemented in a programming – ... language. – In the example, we will have a Book class in Java. Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
  • 23. Page 92 Page 93 From Design to Implementation Software Design Analysis Design Construction  Knowing an object-oriented language and having investigation logical solution code access to a library is necessary but not sufficient in of the problem order to create object software.  In between a nice idea and a working software, there is much more than programming. Book public class Book {  Analysis and design provide software “blueprints”, Book public void print(); illustrated by a modeling language, like the Unified (concept) title private String title; Modeling Language (UML). print() }  Blueprints serve as a tool for thought and as a form of Representation in an Domain concept Representation in communication with others. object-oriented analysis of concepts programming language. Comp6471 Software Design Methodologies Comp6471 Software Design MethodologiesPage 94 Page 95 Software Design Software Design (Cont’d)  How to implement the what.  Some consider software design to be a “black  Requirements Document (RD) is starting point. art”:  Software design is a highly-creative activity. – difficult to prescribe how to do it  Good designers are worth their weight in gold! – hard to measure a good design objectively – Highly sought after, head-hunted, well-paid. – “I know a good design when I see it.”  Experience alone is not enough: – creativity, “vision”, all-around brilliance required. Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies

×