1、1课程回顾课程回顾timeInceptionElaborationConstructionTransition UP项目将其工作和迭代组织为四个主要阶段：u 初始（Inception）：大体上的构想，业务案例，范围和模糊评估u 细化（Elaboration）：已精化的构想、核心构架的迭代实现、高风险的解决、确定大多数需求和范围以及进行更加细致实际的评估u 构造（Construction）：对遗留下来的风险较低和比较简单的元素进行迭代实现，准备部署u 移交（Transition）：进行beta测试和部署。III. 细化迭代I基础3细化迭代I基础 第八章 迭代1基础 第九章 领域模型 第十章 系统
2、顺序图 第十一章 操作契约 第十二章 从需求到设计迭代进化 第十三章 逻辑架构和UML包图 第十四章 迈向对象设计 第十五章 UML 交互图 第十六章 UML类图 第十七章 GRASP：基于职责设计对象 第十八章使用GRASP的对象设计示例4细化迭代I基础 第八第八章章 迭代迭代1基础基础 第九章 领域模型 第十章 系统顺序图 第十一章 操作契约 第十二章 从需求到设计迭代进化 第十三章 逻辑架构和UML包图 第十四章 迈向对象设计 第十五章 UML 交互图 第十六章 UML类图 第十七章 GRASP：基于职责设计对象 第十八章使用GRASP的对象设计示例第八章迭代1基础 定义细化阶段的第一个
3、迭代 描述初始和细化阶段的关键内容6迭代迭代1 细化阶段的迭代1： 需求和重点：OOA/D技术的核心。 其他：数据库、可用性、UI设计（非本课程重点） 回顾：UP是 用户驱动的，架构驱动的迭代 用户需要，以架构为中心风险驱动的 在迭代开发中，我们并非一次实现所有的需求7示例：示例：NextGen POS NextGen POS应用在第一个迭代要处理的需求如下： 实现处理销售用例中基本和关键的场景：输入商品项目并收取现金。 实现用于支持迭代初始化需要的启动用例。 不处理任何特殊和复杂的部分，仅仅针对场景的简单理想路径，并对此进行设计和实现。 不与外部服务进行协作，例如，税金计算器或产品数据库。
4、不应用复杂的定价规则。 对UI支持、数据库等内容的设计和实现也会在本次迭代中进行，但是本书不会涵盖其中细节。8 在多个迭代里对同一用例进行增量式开发。u 用例的实现可能在多个迭代中展开。用例开发用例开发1A use case or feature is often too complex to complete in one short iteration. Therefore, different parts or scenarios must be allocated to different iterations.Use CaseProcess Sale23. . .Use CasePr
5、ocess SaleUse CaseProcess SaleUse CaseProcess RentalsFeature: Logging9细化细化 细化的定义：构建核心架构，解决高风险元素，定义大部分需求，以及预计总体进度和资源。 细化是一般项目中最初的一系列地迭代，其中包括 对核心、有风险的软件架构进行编程和测试。 发现并稳定需求的主体部分。 规避主要风险。 细化阶段通常有两个或者多个迭代组成，每次迭代时间为2-6周。 细化不是不是设计阶段，在该阶段也不是要完成所有模型的开发，以便为构造阶段中的实现做准备。 10细化细化 这一阶段，不是创建可丢弃的原型，该阶段产生的代码和设计都是最终系统的
6、一部分。 称为架构原型（Architectural Prototype） 不是可废弃的，试验性的原型 表示最终系统的产品化子集11细化细化 在细化阶段可能出现的一些关键思想和最佳实践包括： 实行短时间定量、风险驱动的迭代。 及早开始编程。 对架构的核心和风险部分进行适应性的设计、实现和测试。 尽早、频繁、实际的测试。 基于来自测试、用户、开发者的反馈进行调整。 通过一系列讨论会，详细编写大部分用例和其他需求，每个细化迭代举行一次。12细化阶段细化阶段开始构建开始构建的制品的制品制品制品说明说明领域模型领域概念的可视化，类似于领域实体的静态信息模型。设计模型描述逻辑设计的一组图，包括软件类图、对
7、象交互图、包图等软件架构文档学习辅助工具，概括关键架构问题及其在设计中的解决方案。该文档是对重要设计思想及其在系统中动机的概要数据模型包括数据库方案，以及在对象和非对象之间映射的策略用例示意板，用户界面模型描述用户界面、导航路径、可用性模型等13理解细化阶段判断题理解细化阶段判断题 对于大部分项目，细化阶段都需要几个月 只有一次迭代。 在细化开始前就定义了大部分需求。 需要处理有风险的元素和核心架构。 没有产生可执行架构，没有进行产品代码的编程。 细化阶段主要是需求和设计阶段，为软件构造阶段的实现进行准备。 不需要编程之前进行彻底和细致的分析 尽早和实际的测试14计划下一次迭代计划下一次迭代
8、计划和项目管理 通过风险、覆盖范围和关键程度组织需求和迭代。 风险风险包括技术复杂性，也包括其他因素，例如工作量或可用性的不确定性。 覆盖范围覆盖范围意味着在早期迭代中至少要设计系统的所有主要部分或许是对大量构建进行“广泛和肤浅”的实现。 关键程度关键程度是指客户认为具有高业务价值的功能。15需求等级划分需求等级划分等级等级需求（用例或特性）需求（用例或特性）注解注解高处理销售日志所有等级中分值最高的普遍的，以后难以添加中维护用户对安全子域具有影响低 迭代1之前完成等级划分，在迭代2之前要重新划分，因为新需求和新理解会对等级排列产生影响。16细化迭代I基础 第八章 迭代1基础 第九章第九章 领
9、域模型领域模型 第十章 系统顺序图 第十一章 操作契约 第十二章 从需求到设计迭代进化 第十三章 逻辑架构和UML包图 第十四章 迈向对象设计 第十五章 UML 交互图 第十六章 UML类图 第十七章 GRASP：基于职责设计对象 第十八章使用GRASP的对象设计示例第九章领域模型 确定和当前迭代相关的概念类 创建初始的领域模型 为模型建立适当的属性和关联18领域模型领域模型 领域模型 是OO分析中最重要和经典的模型。 是对领域内的概念类或现实世界中对象的可视化表示。 也称为概念模型、领域对象模型和分析对象模型。 UP中的定义“专用于解释特定特定业务领域中的重要事物和产品” 例如，与POS相关
10、的事物。19领域模型领域模型 准则 避免瀑布思维倾向，为完成详尽或“正确”的领域模型而进行大量的建模工作。 过量的建模反而会导致分析停滞，几乎不会有什么回报。20UP制品关系样例制品关系样例P rocess S ale1. C ustom er arrives .2. .3. C ashier enters item identifier.4. U se C ase TextO peration: enterItem ( )P ost-conditions:- . . .O peration C ontractsS aledate. . .S alesLineItemquantity1.*1.
11、 . . . .the dom ain objects, attributes, and associations that undergo state changesD om ain M odelU se-C ase M odelD esign M odel: R egisterenterItem(item ID , quantity): P roductC atalogspec = getP roductS pec( item ID )addLineItem ( spec, quantity ): S ale. . .conceptual classes in the dom ain in
12、spire the nam es of som e softw are classes in the design conceptual classes term s, concepts attributes, associationsC ashier: Item ID : .G lossaryelaboration of som e term s in the dom ain m odelR equire-m entsB usiness M odelingD esignS am ple U P A rtifact R elationships用例中的概念可以作为创建领域模型的输入领域模型又会
13、影响操作契约，词汇表和设计模型，尤其是领域层的软件对象21UML类图类图:POS领域模型领域模型RegisterItemStoreaddressnameSaledate timePaymentamountSalesLineItemquantityStocked-in*Houses1.*Contained-in1.*Records-sale-of 0.1Paid-by1111110.11Captured-on conceptor domain objectassociationattributes难点：奥卡姆剃刀重要性：可视化，规范22领域模型领域模型 领域模型提供了概念透视图（conceptu
14、al perspective），它可以展示 领域对象对象或概念类。 概念类之间的关联关联。 概念类的属性属性。23领域模型领域模型 领域模型是现实世界中事物的可视化，而不是不是具体的软件对象（诸如Java或C#）。因此以下元素不是领域对象领域对象： 软件制品，例如窗口或数据库，除非已建模的领域是针对软件概念的，例如图形化用户界面的模型。 职责或方法。职责或方法。软件对象的职责在设计中非常重要，但是不属于软件模型。24领域模型领域模型 领域模型表示真实世界概念类，而不是软件类不是软件类SaledateTimevisualization of a real-world concept in the
15、 domain of interestit is a not a picture of a software class 领域模型并非表示软件制品或类SalesDatabasesoftware artifact; not part of domain modelavoidsoftware class; not part of domain modelSaledatetimeprint()avoid 报表，计算的结果通常也不是领域对象。25领域模型的概念类领域模型的概念类 领域模型阐述领域内的概念类或词汇。 概念类概念类是思想、事物或对象。 概念类可以从符号符号、内涵内涵和外延外延来考虑。 符号
16、：表示概念类的词语或图形 内涵：概念类的定义。 外延：概念类所使用的一组示例。26概念类：符号、内涵和外延概念类：符号、内涵和外延Saledatetimeconcepts symbolA sale represents the event of a purchase transaction. It has a date and time. concepts intensionsale-1sale-3sale-2sale-4concepts extension27为什么创建领域模型为什么创建领域模型PaymentamountSaledatetimePays-forPaymentamount: M
17、oneygetBalance(): MoneySaledate: DatestartTime: TimegetTotal(): Money. . .Pays-forUP Domain ModelStakeholders view of the noteworthy concepts in the domain.UP Design ModelThe object-oriented developer has taken inspiration from the real world domain in creating software classes. Therefore, the repre
18、sentational gap between how stakeholders conceive the domain, and its representation in software, has been lowered.1111A Payment in the Domain Model is a concept, but a Payment in the Design Model is a software class. They are not the same thing, but the former inspired the naming and definition of
19、the latter.This reduces the representational gap.This is one of the big ideas in object technology.inspires objects and names inq 降低与软件模型之间的表示差异降低与软件模型之间的表示差异28如何建立领域模型如何建立领域模型 以当前迭代中所需要设计的需求为界： 寻找概念类概念类 将其绘制为UML类图类图中的类 添加关联关联和属性属性。29寻找概念类寻找概念类 重用和修改现有的模型 使用分类列表 通过确定名词短语寻找概念类概念类的类别概念类的类别示例示例业务交易准则：关
20、键，作为起点Sale, PaymentReservation交易项目准则：交易中通常会涉及，作为第二SalesLineItem与交易或交易项目相关的产品或服务准则：产品或服务是交易的对象，作为第三ItemFlight, Seat, Meal交易记录于何处准则：重要Register, LedgerFlightManifest30寻找概念类寻找概念类概念类的类别概念类的类别示例示例 place of transaction; place of serviceStoreAirport, Plane, Seatnoteworthy events, often with a time or place
21、we need to rememberSale, Payment, Flightphysical objectsGuideline: This is especially relevant when creating device-control software, or simulations.Item, Register Board, Piece, Die Airplanedescriptions of thingsProduct DescriptionFlight DescriptioncatalogsGuideline: Descriptions are often in a cata
22、log.Product CatalogFlight Catalogcontainers of things (physical or information)Store, Bin Board Airplane31寻找概念类寻找概念类概念类的类别概念类的类别示例示例things in a containerItem Square (in a Board) Passengerother collaborating systemsCredit Authorization SystemAir Traffic Controlrecords of finance, work, contracts, leg
23、al mattersReceipt, LedgerMaintenanceLogfinancial instrumentsCash, Check, LineOfCreditTicketCreditcatalogsGuideline: Descriptions are often in a catalog.Product CatalogFlight Catalogschedules, manuals, documents that are regularly referred to in order to perform workDailyPriceChangeListRepairSchedule
24、32寻找概念类寻找概念类概念类的类别概念类的类别示例示例Physical or tangible objectPOST，AirplaneRoles of peopleCashier，PilotAbstract noun conceptsHunger，AcrophobiaOrganizationsSales DepartmentEventsSale，Meeting，FlightProcessSellingAProduct，BookingRules and policiesRefundPolicy33分类列表示例分类列表示例 例如：POS里的处理销售用例POSTerminalItemSalesLi
25、neItemCashierStoreProductSpecProductCatalogCustomerPaymentSale34寻找概念类寻找概念类 重用和修改现有的模型 使用分类列表 通过确定名词短语寻找概念类 对领域的文本性描述中识别名词和名词短语，将其作为候选的概念类或属性。 使用时必须小心，不存在名词到类的映射机制，并且自然语言的词语具有二义性。35名词短语示例名词短语示例 主成功场景（或基础流程）：1 顾客顾客携带所购商品商品或服务服务到收银台通过POSPOS机付款。2 收银员收银员开始一次新的销售销售交易。3 收银收银员输入商品条码。商品条码。4 系统逐条记录出售的商品商品，并显示
26、该商品的描述、价格和累计额。价格通过一组价格规则来计算。5 系统显示金额和所计算的税金税金。6 收银员告知顾客总额，并请顾客付款付款。7 顾客付款，系统处理支付。8 系统记录完整的销售销售信息，并将销售和支付信息发送到外部的账务系统账务系统（进行账务处理账务处理和提成提成）和库存系统库存系统（更新库存）。9 系统打印票据票据。10 顾客携带商品和票据离开（如果有）。36找到概念类示例：找到概念类示例：POS 为迭代1所考虑的处理销售的用例找到概念类：Sale，Cashier，Cash，PaymentCustomer，Sales Line ItemStore，Item，Product Descr
27、iptionRegister，Product Catalog，Ledger37准则：敏捷建模准则：敏捷建模 绘制类图的草图草图。 类框底部和右侧呈开放状态，这样方便扩展。38准则：敏捷建模准则：敏捷建模 使用工具维护模型 早期，会遗漏概念和不完美，后期会不断发现这些类。 在敏捷建模里，创建领域模型示为了快速理解和沟通关键概念。 完美不是目的，敏捷模型在创建后很快被抛弃。 基于此，没必要维护或更新这些模型。 如果有人希望有新发现是可以维护和更新模型 可以使用UMLCASE工具绘制领域类图39准则：是否包含报表对象准则：是否包含报表对象 在POS领域中，票据是重要术语，但是也许它只是销售和支付数据
28、的报表，因此是一种信息重复，是否应该将票据包含在领域模型里：不包含：在领域模型中显示其他信心的报表没有意义，因为其所有信息都是源于其他信息源的。包含：它有特殊的作用：通常持有（纸质）票据的人有提货的权利。 例如，在迭代1里没有考虑退货，那么不应该包括票据。在解决处理退货时再考虑包含。 例如：超市资助存包机打印的存包条码是不是对象？40准则：准则：Think like a mapmaker 以地图绘制者的工作思维创建领域模型：使用地域中现有的名称。例如，假设在开发图书馆模型，将顾客命名为“借书者”或“赞助者”排除无关或超出范围的特性。不凭空增加事物。41准则：属性与类的常见错误准则：属性与类的常
29、见错误 常见错误：应该是概念类的事物表现为属性。 预防的经验：如果我们认为某概念类X不是现实世界中的数字或文本，那么X可能使概念类而不是属性。属性：用数字或文本表达，例如商品编码。商品是类，编码是其重要属性。SaleStorephoneNumberSaleStore42准则：属性与类的常见错误准则：属性与类的常见错误 常见错误：应该是概念类的事物表现为属性。 预防的经验：如果我们认为某概念类X不是现实世界中的数字或文本，那么X可能使概念类而不是属性。属性：用数字或文本表达，例如商品编码。商品是类，编码是其重要属性。FlightAirportnameFlightdestination43准则：描
30、述类准则：描述类 描述类包含描述其他事物的信息。例如，ProductDescription记录item的价格、图片和文字描述。Item instance 商品实例表示商店里实际商品，它可以拥有一个编号。每个商品item具有描述、价格和ID，这些内容不会再其他任何地方记录。商店里的每个工作人员都健忘。售出实际商品，响应的item instance就会从“软件领域”中删除。44准则：描述类准则：描述类 例如，在apple store里的iPhone，市场需求巨大，销售火爆，objectiphone的所有item实例都被从计算机存储器里删除。那么有人询问iphone的各种参数和价格，就没有记录了？
31、如果软件模型类似于领域模型，那么会重复数据。因为描述、价格和ID对于同一个产品的每个实例都是重复的。45准则：描述类准则：描述类 为什么需要增加描述类： 需要有关商品和服务的描述，独立于任何商品或服务的现有实例 删除所描述的实物的实例后，导致信息丢失，而这些信息是需要维护的，但是被错误地与所删除的事物关联起来。 减少冗余或重复的信息。 对象需要其他事物来 记录其描述，所以用描述类来记录商品的信息。46准则：描述类准则：描述类ItemserialNumberItemdescriptionpriceserialNumberitemIDproductDescriptiondescriptionpri
32、ceitemID1 * 对象需要其他事物来 记录其描述，所以用描述类来记录商品的信息。 某个item拥有特有的序列号，用于表示其物理实例。ProductDescription没有序列号。 转换到软件角度，即使所有库存的商品卖光，软件实例都删除，ProductDescription仍然在。47关联关联 关联（Association）是类之间的关系，表示有意义和值得关注的连接 UML中，关联定义为“两个或多个类元之间的语义联系，涉及这些类元实例之间的连接。”48准则：关联准则：关联 何时表示关联： 关联吊事需要持续一段时间的关系，可能几毫秒可能几年，那么何时需要记录？ 如果存在需要保持一段时间需要
33、保持一段时间的关系，将这种语义表示为关联。 注意，仍然是基于现实领域的需要，而不是软件需要。 例如：saleline item实例和sale实例之间，要记录用来打印，再现，退货，账务等。 例如：Monopoly，记录棋子在哪个位置，不需要记录骰子点数。49准则：关联准则：关联 避免大量关联： N个节点的图中，可以有（n*（n-1）/2个关联，可能非常大的数字。 连线太多，视觉干扰，图变得混乱。 重点只关注需要记录的关联。50准则：关联准则：关联 关联是否在软件中实现？ 在领域建模时，关联不是软件中数据流、数据库的联系，而是针对现实领域的春概念角度看的有意义的关系。 大部分关系将作为导航和可见性
34、路径在软件中实现。 但是领域模型不是数据模型，添加关联是为了突出我们对重要对重要关系关系的理解，而不是记录对象或数据的结构。 51UML表示关联表示关联 在UML图中，关联被表示为类之间的连线，冠以首字母大写的关联名称。52UML中对关联命名中对关联命名 以“类名-动词短语-类名”的格式为关联命名53UML：对关联命名：对关联命名 以“类名-动词短语-类名”的格式为关联命名 少使用“拥有”或者“使用”这样的简单关联名称，因为不会增加对领域的理解。 例如 Sale Uses CashPayment改为Sale Paid-by CashPayment Player Has Square改为Play
35、er Is-onSquare。 关联名称，首字母大写： Records-current或RecordsCurrent54UML：角色：角色 关联的每一端称为角色（Role） 多重性表达式 名称 55UML：多重性：多重性 多重性：定义了类A有多少个示例可以和类B的一个实例关联。 例如：Store的一个实例可以和Item的多个实例关联。（*表示零个或多个）ItemStoreStocks*multiplicity of the role156UML：多重性：多重性 多重性的值表示在特定时刻（而不是某个时间跨度内）的关联实例数量。 例如：二手车可能一段时间会卖给多个经销商，但是某个时刻只会stock
36、ed by一个经销商。ItemStoreStocks*multiplicity of the role157UML：多重性：多重性ItemStoreStocks*multiplicity of the role1zero or more; manyone or moreone to 40exactly 5TTTT*1.*1.405T3, 5, 8exactly 3, 5, or 858UML：两个类之间的多重关联：两个类之间的多重关联 两个类之间可能有多重关联。例如，航空领域 Flies-to Flies-fromFlightAirportFlies-toFlies-from*1159准则：如
37、何在关联列表中找到关联。准则：如何在关联列表中找到关联。CustomerPaymentPassengerTicketA is a role related to a transaction BItemSalesLineItem (or Sale), FlightReservationA is a product or service for a transaction (or line item) BSalesLineItemSaleA is a line item of a transaction BCashPaymentSaleCancellationReservationA is a t
38、ransaction related to another transaction BExamplesCategory 根据下述列表添加关联，该列表中包含值得考虑的常见类别，示例选自POS，Monopoly和航空预订领域60准则：如何在关联列表中找到关联。准则：如何在关联列表中找到关联。SalesLineItemSalesLineItem, SquareSquare, CityCityA is next to BCashierRegister, PlayerPiece, PilotAirplaneA uses or manages or owns BDepartmentStore, Maint
39、enanceAirlineA is an organizational subunit of BCashierStore, PlayerMonopolyGame, PilotAirlineA is a member of BSaleRegister, PieceSquare, ReservationFlightManifestA is known/logged/recorded/ reported/captured in BProductDescriptionItem, FlightDescriptionFlightA is a description for BRegisterStore,
40、ItemShelf, SquareBoard, PassengerAirplaneA is physically or logically contained in/on BDrawerRegister, SquareBoard, SeatAirplaneA is a physical or logical part of BExamplesCategory61关联示例：关联示例：POSSales LineItemquantitySaledatetimePaymentamountStoreaddressnameItemPOSTRecords-sale-onStocksHousesCapture
41、d-onContained-inPaid-by11 1.*10.111111.*CustomerCashierManagerProduct CatalogProductDescription11Is-forInitiated-byLogs-completedDescribed-byRecords-sale-ofContainsDescribes110.1*111111.*11*1Used-byStarted-by1*Ledger11A与B是相关交易A是B交易中的项目A是B交易对应的产品62关联示例：关联示例：Monopoly游戏游戏 通过需要记住的标准和常见分类列表得来的。63属性属性 属性（
42、Attribute）是对象的逻辑数据值。 何时需要展现属性?当需求建议或暗示需要记住信息是，引入属性。例如：处理销售的票据含有日期和时间、店名和地址以及收银员ID等。 Sale需要dateTime属性，store需要name和address，cashier需要IDSaledateTime/ total : Moneyattributesderived attribute64UML表示属性表示属性 属性在类框图的第二格中表示，其类型和其他信息是可选的。 UML中属性的完整语法是 visibility name：type multiplicity= default property-stringS
43、aledateTime/ total : Moneyattributesderived attribute65UML表示属性表示属性 UML中属性的完整语法是 visibility name：type multiplicity= default property-stringSale- dateTime : Date- / total : MoneyPrivate visibility attributesMath+ pi : Real = 3.14 readOnlyPublic visibility readonly attribute with initializationPersonfi
44、rstNamemiddleName : 0.1lastNameOptional value66UML表示属性表示属性 导出属性derived attributes：Sale中的total属性可以从salelineitem中的信息计算或导出收银员输入的数量可以被记录为saleslineitem的属性，但是该数量也可以从关联的多重性的实际数值计算而来，所以被表示为导出属性，在属性名称前加“/”符号67UML表示属性表示属性 导出属性derived attributes：68属性类型属性类型 UML中属性的完整语法是 visibility name：type multiplicity= defaul
45、t property-string 属性类型： 关注领域模型中的数据类型，例如数字、布尔、日期，字符等。 不应当是复杂的领域概念，如sale或airportCashiernamecurrentRegisterCashiernameRegisternumberUsesWorseBetternot a data type attribute1169属性类型属性类型 常见错误：将复杂领域概念建模为属性 Eg：机场不是字符串而是复杂的实物。 通过关联而不是属性来表示概念类之间的关系。FlightFlightdestinationWorseBetterFlies-toAirport11destinati
46、on is a complex concept70属性类型属性类型 基本的数据类型包括诸如：数字、布尔、字符、字符串和枚举（例如，尺寸=小，大）。 但是在领域模型中，有时候需要根据特定领域来制定一些新的数据类型类来表示原为数字或字符串的数据：由不同小节组成的电话号码和人名具有与之相关的操作，如解析或校验:如社会安全号具有其他属性促销价格可能有开始日期和结束日期有单位的数量支付总额有货币单位71数据类型类数据类型类 UML表示对象的数据类型特性的两种方式：OKOKProductDescriptionProductDescriptionitemId : ItemID1StoreStoreaddre
47、ss : Address111ItemIDidmanufacturerCodecountryCodeAddressstreet1street2cityName.72属性属性 准则：数量要有单位Paymentamount : NumberPaymentQuantityamount : NumberUnit.Paymentamount : QuantityHas-amount1*Is-in1*not usefulquantities are pure data values, so are suitable to show in attribute sectionbetterPaymentamou
48、nt : Moneyvariation: Money is a specialized Quantity whose unit is a currency73属性示例：属性示例：POS74属性示例：属性示例：POS75RegisterItemStoreaddressnameSaledate timePaymentamountSalesLineItemquantityStocked-in*Houses1.*Contained-in1.*Records-sale-of 0.1Paid-by1111110.11Captured-on conceptor domain objectassociatio
49、nattributes领域模型完成领域模型完成76UP中的领域模型中的领域模型s 软件架构文档 rs 设计模型设计 rs词汇表 rs补充性规格说明 rs设想 rs用例模型需求 s 领域模型领域模型业务建模C1.CnE1.EnI1迭代 构造细化初始.制品科目 S：开始；R：精化77小结小结 领域模型：是对领域内概念类和现象的可视化表示。 寻找概念类概念类 将其绘制为UML类图类图中的类 去除界面，数据库，报表，属性 添加关联关联和属性属性。78期中大作业期中大作业 分组：2-3名同学一组。11月22日之前确定。 大作业 案例研究Case Study 要求：自选话题（可以为软件项目，或科研项目/论
50、文/我爱发明等节目，或其他相关主题），但是要求选出的案例可以根据课堂介绍的方法，进行需求分析与领域分析，生成用例模型和领域模型。 作业成果为课堂演示ppt和整理的报告。报告上交和课堂演示时间为11月29日。 每组展示时间10-15分钟。 占总成绩30%案例研究需求分析与领域分析学号学号姓名姓名主要贡献主要贡献描述每个人的贡献，例如：“负责和撰写问题陈述”“编写了XX文档XX用例”，“绘制了XX用例模型，领域模型”，“编写作业报告和ppt”小组成员小组成员问题陈述问题陈述 Why？几句话描述为什么需要此软件/项目/研究。 What？此软件/项目/研究的现况如何（别人怎么做了），还有什么需要解决的
