2019/5/12 Object-oriented Analysis and Design Object-oriented - PDF document

2019/5/12 Object-oriented Analysis and Design Object-oriented Analysis and Design Chapters Iteration 1 – basics 8. Applying UML and Patterns Domain models 9. 10. System sequence diagrams 11. Operation contracts An Introduction to 12. Requirements to design – iteratively Object-oriented Analysis 13. Logical architecture and UML package diagrams and Design 14. On to object design and Iterative Development 15. UML interaction diagrams 16. UML class diagrams Part III Elaboration Iteration I – Basic 1 17. GRASP: design objects with responsibilities 18. Object design examples with GRASP 19. Design for visibility 20. Mapping design to code 21. Test-driven development and refactoring Software Engineering Software Engineering 1 2 Object-oriented Analysis and Design Object-oriented Analysis and Design Chap 12 Requirements to Design Iteratively Software Engineering Software Engineering 3 4 Object-oriented Analysis and Design Object-oriented Analysis and Design ★ ★ Iteratively Provoking Early Change Do the Right Thing, Do the Thing Right  It is natural to change some requirements during the  Object-oriented requirements analysis design and implementation work, especially in the early  focused on to do the right thing; iterations.  understanding some of the outstanding goals, and related rules  Iterative and evolutionary methods "embrace change“ and constraints.  The following design work stress to do the thing right  to have a more stable goal (and estimate and schedule) for the later iterations.  skillfully designing a solution to satisfy the requirements for this iteration.  Early programming, tests, and demos help provoke the  In iterative development, a transition from primarily inevitable changes early on. requirements/ analysis to primarily design and  The discovery of changing specifications will both implementation in each iteration. clarify the purpose of the design work of this iteration  Early iterations will spend more time on analysis activities. and refine the requirements understanding for future  Later iterations it is common that analysis lessens; there's iterations. more focus on just building the solution. Software Engineering Software Engineering 5 6 1

2019/5/12 ★ Object-oriented Analysis and Design Object-oriented Analysis and Design Didn't All That Analysis and Modeling Take Weeks To Do  The duration to do all the actual modeling (use case Chap 13 writing, domain modeling..) that has been explored so far Logical Architecture and is realistically just a few hours or days .  Many other activities of project planning, such as proof- UML Package Diagrams of-concept programming, finding resources (people, software, …), planning, setting up the environment could consume a few weeks of preparation. Software Engineering Software Engineering 7 8 Object-oriented Analysis and Design Object-oriented Analysis and Design POS Example: OOD vs. LA Partial Layered, Logical Architecture UI not the Java Swing libraries, but Swing Web Our GUI classes Based on Swing Domain Sales Payments Taxes Technical Services Persistence Logging RulesEngine https://blog.csdn.net/pmlpml/article/details/53439095 Software Engineering Software Engineering 9 10 真实 Web 系统的分层逻辑架构 Object-oriented Analysis and Design Object-oriented Analysis and Design ★ ★ Software Architecture Logical Architecture  An architecture  Logical architecture  the large-scale organization of the software classes into  the set of significant decisions about the organization of packages (or namespaces), subsystems, and layers . a software system,  there's no decision about how these elements are deployed  the selection of the structural elements and their across different operating system processes or across interfaces by which the system is composed physical computers in a network (these latter decisions are  their behavior as specified in the collaborations among part of the deployment architecture). those elements,  the composition of these structural and behavioral  逻辑架构是关于类的分类和组织 ， 即将类分类到包 、 elements into progressively larger subsystems, 子系统或层 。 与应用领域相关 ， 但与硬件 、 操作系统  the architectural style guides this organization, these 和生产环境关系无关的决策 elements and their interfaces, their collaborations, and their composition. Software Engineering Software Engineering 11 12 2

2019/5/12 Object-oriented Analysis and Design Object-oriented Analysis and Design ★ ★ Layer Architecture Applying UML: Package Diagrams 1  Layers in an OO system include:  UML package diagrams are used to illustrate the logical  User Interface. architecture of a system, the layers, subsystems, packages.  Application Logic and Domain Objects  A layer can be modeled as a UML package; e.g., the UI  representing domain concepts (e.g. software class Sale) that fulfill layer modeled as a package named UI. application requirements, such as calculating a sale total.  A UML package diagram provides a way to group  Technical Services elements.  provide supporting technical services, such as interfacing with a  can group anything: classes, other packages, use cases... database or error logging. These services are usually application-  Nesting packages is very common, java::util::Date. independent and reusable across several systems.  A UML package is a more general concept than simply a  In network protocol stacks, a layer only calls upon the services Java package or .NET namespace. of the layer directly below it(strict layered architecture).  To show dependency (a coupling) between packages so that  Information system usually has a relaxed layered architecture, developers can see the large-scale coupling in the system. in which a higher layer calls upon several lower layers.  a dashed arrowed line with the arrow pointing towards the depended-on package. Software Engineering Software Engineering 13 14 Object-oriented Analysis and Design Object-oriented Analysis and Design Applying UML: Package Diagrams 2 Guideline: Design with Layers 1  Organize the large-scale logical structure of a system into discrete  to show package nesting, using embedded packages, layers of distinct, related responsibilities, with a clean, cohesive UML fully-qualified names, and the circle-cross symbol separation of concerns such that the "lower" layers are low-level and general services, and the higher layers are more application specific.  Layers helps address problems Domain UI  Source code changes are rippling throughout the system, many parts of the systems are highly coupled. Swing Sales Web  Application logic is intertwined with the user interface, so it cannot be reused with a different interface or distributed to another processing node.  technical services or business logic is intertwined with more UI UI::Swing UI:: Web application-specific logic, so it cannot be reused, distributed to another node, or easily replaced with a different implementation.  There is high coupling across different areas of concern. It is thus Swing Web Domain::Sales difficult to divide the work along clear boundaries for different Domain developers. Sales Software Engineering Software Engineering 15 16 Object-oriented Analysis and Design Object-oriented Analysis and Design ★ ★ ★ Guideline: Design with Layers 2 Layers in IS Logical Architecture GUI windows  Benefits of Using Layers reports UI speech interface (AKA Presentation , View)  A separation of high from low-level services, and of HTML, XML, XSLT, JSP, Javascript, ... more app application-specific from general services. This reduces handles presentation layer requests specific workflow Application session state coupling and dependencies, improves cohesion, increases (AKA Workflow, Process, window/page transitions dependency Mediation, App Controller) consolidation/transformation of disparate reuse potential, and increases clarity. data for presentation handles application layer requests  Related complexity is encapsulated and decomposable. implementation of domain rules Domain domain services ( POS , Inventory ) (AKA Business,  Some layers can be replaced with new implementations. - services may be used by just one Application Logic, Model) application, but there is also the possibility of multi-application services This is generally not possible for lower-level Technical very general low-level business services Service or Foundation layers (e.g., java.util), but may be Business Infrastructure used in many business domains (AKA Low-level Business Services ) CurrencyConverter possible for UI, Application, and Domain layers.  Lower layers contain reusable functions. (relatively) high-level technical services Technical Services and frameworks (AKA Technical Infrastructure,  Some layers (primarily the Domain and Technical Services) Persistence , Security High-level Technical Services ) can be distributed.  Development by teams is aided because of the logical low-level technical services, utilities, Foundation and frameworks (AKA Core Services , Base Services , segmentation. data structures, threads, math, Low-level Technical Services /Infrastructure) file, DB, and network I /O width implies range of applicability Software Engineering Software Engineering 17 18 3