《软件工程》ComputerScience上.ppt

Computer Science 306 1/15/03,Bill Bond,Class Communication,Email your name and email address to Normally will post notes before class Assignments got to Web page should be in following location: /umreec/web-courses/,Software Crisis,Programs dont reflect customer desires Schedule and cost estimates are often grossly inaccurate “Productivity” of software people has not kept pace with the demand for their services Software complexity increases Quality of software is sometimes less than adequate Difficult to maintain existing programs,The Problem,Building computer solution is hard Understand problem Design solution Implement solution Complexity is the problem Lots to do Lots to keep track of,Software Engineering,Managing complexity by imposing discipline Abstraction - focus only on essential details, ignore others (for now) Decomposition - break into manageable pieces Analysis/Design methods and Tools support these ideas,Large Projects,Require Teams Key elements Communication - has cost Artifacts - support communication,Artifacts,Which should be produced? “Discovery” value Which should be maintained? Maintenance value Recognize cost of producing artifacts,Software Engineering,Book definition The establishment and use of sound engineering principles in order to obtain economical software that is reliable and works efficiently on real machines,Result,Comprehensive methods “how to” Process context in which technical methods applied, deliverables produced Better tools More powerful building blocks Better quality assurance Communication,Three Generic Phases,Definition phase What Information to be processed Function/Performance desired System Engineering Software Project Planning Requirements Analysis,Three Generic Phases, cont,Development phase how Software architecture Implementation Testing,Three Generic Phases, cont,Maintenance phase change Correction defect correction Adaptation supports new environment Enhancement Prevention changes to allow correction, adaptation, enhancement,Course Description,All aspects of software engineering Project management Requirements Analysis Design Implementation Testing More,Introduction to Object-Oriented Analysis and Design,Bill Bond 10/16/02,Schedule,10/16 - Background 10/23 - Exam 10/30 - Analyze - Use Cases, Domain Model 11/6 - Design - Collaboration / Design diagrams 11/13 - Construct - Code 11/20 - Complete, Begin examples 11/27 - No class 12/4 - Examples 12/11 - Project due, UML Odds and Ends 12/18 - Final Exam,Chapter 1 - Goals,Describe Process Repeatable, predictable results Requirements development Use Cases Conceptual Model Design Model Sequence Diagrams Produce code,Goals,Learn basic set of UML Unified Modeling Language Capture Analysis/Design Communicate with other developers Apply “good” design principles Patterns (good design solutions) Work examples,Part of Engineering Process,Estimating Planning/Scheduling Configuration Management Change Control Peer Reviews Testing,Unified Modeling Language,Industry standard Rational proposal Booch - Booch diagrams Model diagrams Rumbaugh - Object Modeling Technique Model diagrams Jacobson - Objectory Process,Unified Modeling Language,Set of Diagrams Different views of a system Concentrate on a subset Use cases Sequence / Collaboration diagrams Dynamic (Execution) view Conceptual / Design model Static view - can produce code,Unified Modeling Language,Does not define an approach But we will - Unified Process,Artifacts,What artifacts should be produced? What artifacts should be peer reviewed? What artifacts should be maintained? Design evolves over time,Artifacts,Represent cost Improved process repeatability Improved design / quality through self-discovery Improved design / quality through peer review,What Does Customer Want?,Reasonable cost Delivered on schedule Meets requirements High quality,Analysis / Design,Analysis (what) - Investigation of the problem domain, rather than how the solution is defined Design (how) - Logical solution, how system fulfills the requirements,Analysis / Design,Analysis,Design,What Requirements Investigation of Domain,How Logical solution,Function-Oriented Approach,Decomposition is primary strategy Construct a “control” hierarchy,Control,I/O,Processing,OOA /OOD,Consider problem domain /solution from the perspective of objects OOA - Find and describe domain (problem space) objects OOD - Define logical software objects that will be implemented in an Object-Oriented Programming Language,Approach,Assign responsibilities to components Important question (should be able to answer) - What is this component responsible for? What does it do (exactly)? Find suitable objects / abstractions Domain (Conceptual) model - Representation - Code,Is An Object-Oriented Language Required?,No,Business Example,Textual narrative description of business processes External actors - cause business to process data Results produced by interaction between people Expectations - what should be the outcome? Use case,Business Example,People roles What “categories” of people participate in the domain Responsibilities Conceptual (domain) model Interactions How collaboration occurs to achieve overall goals Collaboration (sequence) diagrams,Chapter 2 - Macro Process,Development Process - Organize software activities for creation, delivery, and maintenance Macro level Plan and Elaborate Build Deploy,Plan and Elaborate,Plan - schedule, resources, budget Preliminary investigation report Requirements investigation Glossary Prototype Use Cases - text Use Case Diagrams Draft Conceptual Model,Unified Process,Book describes a simplified version of the Rational Unified Process A “typical” OOA / OOD process,Iterative Development,Successive refinement through multiple cycles (adding more functions) of Analysis Design Implementation Test Waterfall - a single cycle,Iterative Development,Each iteration produces an executable but incomplete system System may not be eligible for production deployment for many iterations Iteration output is not a “throw-away” prototype, it is a production-grade subset of the final system,Benefits,Early rather than late mitigation of high risks (technical, requirements, usability, etc.) Early visible progress Early user feedback Managed complexity Development feedback can be used to update the process,Waterfall,Iteration,Iterations,Time Boxing - Fixed time iteration cycle Choose iteration requirements carefully Organized by Use Cases Each iteration implements a set of use cases,Advantages,Iterations,Work Activities,UP Best Practices,Tackle high-risk, high-value issues early Continuously engage users Build cohesive, core architecture early Continuously verify quality through test Model software visually with UML Carefully manage requirements Practice change request and configuration management,Chapter 4 - Inception,Envision the product scope, vision, and business case The main problem: Do the stakeholders have basic agreement on the vision of the project, and is it worth investing in serious investigation?,Chapter 5 - Requirements,Requirements are capabilities and conditions to which the system must conform,UP Requirements,Manage requirements - define and stabilize the requirements - in the context of inevitably changing and unclear stakeholders wishes, a systematic approach to finding, documenting, organizing and tracking the changing requirments of a system,“Challenged” Projects,FURPS+,Functional - features, capabilities, security Usability - human factors, help, documentation Reliability - frequency of failure recoverability, predictability Performance - response times, throughput, accuracy, availability, resource usage Supportability - adaptability, maintainability, internationalization, configurability,The +,Implementation - resource limitations, languages and tools, hardware Interface - constraints imposed by interfacing with external systems Operations - system management in its operational setting Packaging Legal - licensing and so forth,Requirements Development,Get it written down (shalls) Can be verified Get consensus with user,Next,Use Cases Domain Models,Object-Oriented Analysis Use Cases, Domain Model,Bill Bond 10/30/02,Chapter 6 - Use Cases,Use case - Narrative description that describes sequence of events of an actor (external agent) using system to complete a process (documents responses). Actor Human Another system,Example,Use case: Buy Items Actors: Customer, Cashier Description: A customer arrives at a checkout with items to purchase. The cashier records the purchase items and collects payment. On completion, the Customer leaves with the items.,Use Case,No rigid format Alternative solutions Handled at end Mistake -identify individual steps as a use case Use case usually includes many steps,Actor,External Entity Stimulates system Receives response Capitalize to identify,Actor,Initiator actor Participating actors Kinds of actors Roles that people play Computer systems Electrical or mechanical devices,Identifying Use Cases,Actor-based Identify actors related to a system For each actor, identify the processes they initiate or participate in Event-based Identify the external events that the system must respond to Relate the events to actors and use cases,UML Notation,Traceability,Functions should all be allocated to Use Cases Via cross reference verify all functions have been allocated,System Boundary,Examples Hardware/software boundary of device/computer system Defines systems responsibilities Depends on Intent,Example,Log In,Refund,Buy Items,Refund,Buy Items,POST,Store,Cashier,Customer,Customer,Use Case Refinement,Real Very concrete Design details User interface,Essential Very abstract,Which best supports testing?,Naming,Start with verb It is a process,Decisions and Branching,Main: If _, see section X If _, see section Y X: Y: ,Using Use Cases,Define system boundary, actors, use cases Write use cases in high-level format Draw Use Case diagram Relate Use Cases For critical, influential, risky use cases, expand detail Rank Use Cases for implementation,Chapter 7,Chapter 8 - Scheduling,Ranking and scheduling Use cases Assuming desired artifacts produced (requirements, use cases), transition to iterative development,Ranking,Significant impact on architectural design Significant information and insight regarding design, with little effort Risky, time-critical, complex Significant research Primary processes Directly support increased revenue / decreased cost,“Start Up”,May not rank high Provides initialization used by other use cases Often “falls out”,Chapter 9 - System Sequence,System sequence diagram - for a particular scenario of a use case the events that external actors generate, their order Time proceeds downward Order of events follow use case,Construction,Draw line representing system as black box Identify each actor, draw line From use case, identify external events that each actor generates - Illustrate on diagram Optionally include use case text System boundary must be clear Naming operations - begin with verb,Chapter 10 - Domain Model,Representation of “real-world” things Static structure diagram Contents Concepts Associations between concepts Attributes of concepts Tool of communication,Not Software Design,Following should not be in model No software artifacts - window/database No responsibilities or methods,Concept,Idea Thing Object May be defined using Symbol - word representing a concept Intension - definition of a concept Extension - set of examples to which the concept applies,Approach,Decompose domain into concepts Strategy to identify concepts Guideline - better to over specify with many fine-grained concepts, than to under specify it Do not exclude concept because requirements do not indicate any need to “remember” information or it has no attributes Use domain vocabulary,Concept Category List,Physical or tangible objects Specifications or descriptions of things Places Transactions Transaction line items Roles of people Containers of other things Things in a container,Concept Category List,Other computer or mechanical systems external to our system Organizations Events Processes Catalogs, manuals, books Records of finance, work, contracts, legal matters,Noun Phrase Identification,Noun and noun phrases in textual description of problem domain Some may be attributes,Construction of Domain Model,List candidate concepts using Concept Category List, Noun Phrase Identification Draw domain model add associations necessary to record relationships for which there is a need to preserve some memory Add the attributes necessary to fulfill information requirements,Example,Concept or Attribute?,If we do not think of some concept as a number or text in the real world, X is probably a concept, not an attribute,Specification,Description of item, distinct from item Use specification when: Deleting instances of things results in a loss of information It reduces redundant or duplicate information,Chapter 11- Adding Associations,Association - relationship between concepts that indicates some meaningful and interacting connection,UML Association Notation,Guidelines,Focus on associations for which knowledge of the relationship needs to be preserved for some duration It is more important to identify concepts than associations Too many associations tend to confuse domain model rather than illuminate it Avoid showing redundant or derivable associations,Common Association List,A is a physical part of B A is a logical part of B A is physically contained in B A is logically contained in B A is a description for B A is line item of a transaction/report in B A is known/logged/recorded/reported/ captured in B,Common Association List,A is a member of B A is an organizational subunit of B A uses or manages B A communicates with B A is related to a transaction B A is next to B A is owned by B,High Priority,A is a physical or logical part of B A is physically or logically contained in B A is recorded in B Remove associations not required by requirements, could change with requirements,Association,Each end of an association is called a role Name Multiplicity expression Naming associations TypeName VerbPhrase Ty