Slide 1What will we learn?Moving from Analysis to DesignAnalysis vs DesignArtifacts InteractionSlide 6Slide 7Logical ArchitectureLogical Architecture: The Layer ModelLogical ArchitectureUML Package DiagramsSlide 12Slide 13Design with LayersDomain Layer and Domain ModelSlide 16Layer Do’s and Don’tsSSDs, System Operations, LayersSlide 19Logical Architecture for POS and MonopolySlide 21Designing ObjectsSlide 23Designing Objects (cont.)Object-Oriented Design: OverviewDesign Patterns: IntroductionThe Model-View-Controller (MVC) ArchitectureTakeaways from Chapter 12, 13, 14Next …Object-Oriented Analysis and DesignCHAPTERS 12-14: INTRODUCTION TO DESIGN1What will we learn?Introduction to the Logical Architecture and layersHow to use UML package diagrams Understanding the static versus dynamic object modeling2Moving from Analysis to DesignSo far we have studied …How to create use casesHow to create a Domain ModelHow to create SSDs and Operations ContractsThese are the main tools in OOA, i.e. they help explore and define what the system doesWe will now move to design, where we define how the system worksNote that this may still be part of the Agile UP process: Analysis and design are occurring at the same time as requirements are refined3Analysis vs DesignA bad domain model will mean bad communication of the what the system is; a bad design model often leads to a bad implementationMaking the correct choices now becomes more importantHere is where iterative development can help – constant feedback and requirements enhancement can help the design evolve correctlyNote the initial requirements analysis phase may be very short, and of course coding can start immediately4Artifacts InteractionWe are now ready to begin to build the Design Model artifactKey influences: Most of the artifacts we have already worked on influence the Design Model:Use-Case ModelVisionSupplementary SpecificationGlossaryDomain ModelThe Logical Architecture (LA) is part of the Design Model artifact, and is often shown using package diagrams (we will learn about these shortly)Note the interaction diagrams (which are dynamic) and class definition diagrams (which are static) are also part of the Design Model artifact56: RegisterenterItem(itemID, quantity): ProductCatalogspec = getProductSpec( itemID )Require-mentsBusiness ModelingDesignSample UP Artifact RelationshipsVision GlossaryThe logical architecture is influenced by the constraints and non-functional requirements captured in the Supp. Spec.Domain Model**SupplementarySpecificationUse-Case ModelRegister...makeNewSale()enterItem(...)...ProductCatalog...getProductSpec(...)...11class diagrams(a static view)interaction diagrams(a dynamic view)UIpackage diagramsof the logical architecture(a static view)DomainTech ServicesDesign Model7DomainUISwingnot the Java Swing libraries, but our GUI classes based on SwingWebSales Payments TaxesTechnical ServicesPersistence Logging RulesEngineLogical ArchitectureThe Logical Architecture is a large-scale organization of the software classes into packages, subsystems, and layers. Logical: Implies that there is no decision about how these elements are actually deployed on physical systems, i.e. how many computers will host the system, how they are connected, etc.The LA organizes the software classes into layers, which are just collections of classesEach layer is made up of similar classes that have similar responsibilities for a major aspect of the systemNormally, the higher or upper layers call upon the services of the lower layers, but not viceversa8Logical Architecture: The Layer Model9Name PurposeUser Interface (UI) Software objects that directly interact with the user, e.g. GUI interface formsApplication Logic and Domain ObjectsSoftware objects representing domain concepts that fulfill application requirements, such as calculating a totalTechnical Services General purpose objects and subsystems that provide supporting technical services, e.g. error logging or interfacing to a database. Usually reusable objects that are used across multiple applicationsThese are types of layers – the actual model may have moreLogical ArchitectureIn a strictly layered model, each layer only calls the services of the layer below itFor information services, the layered model is usually considered relaxedFor example, the GUI may utilize logging, or a form may directly access a database for a queryWe will primarily concentrate on the middle layer, the Domain or Application Logic layerFor UI, we will primarily be concerned with how it interacts with the middle layer10UML Package DiagramsWe saw this concept when we were developing domain models – it is a way to organize the model into sub-models, with a “folder” notation for easier readingOften used to illustrate the logical architectureModel a layer as a packageThe UML package diagram provides a way to group elements – can be used to group classes, other packages, etc.Common to show dependency between packages – use a UML dependency line (dashed arrow pointing towards depended-on package)UML package provides a namespace, which allows classes to be defined differently in different packagesSome UML CASE tools will reverse engineer code into packages1112Domain::SalesUI::WebUI::SwingSalesWebSwingUIDomainDomainUISwingSalesWeb13UI(AKA Presentation, View)Application(AKA Workflow, Process,Mediation, App Controller)Domain(AKA Business, Application Logic, Model)Technical Services(AKA Technical Infrastructure, High-level Technical Services)Foundation(AKA Core Services, Base Services,Low-level Technical Services/Infrastructure)width implies range of applicability GUI windows reports speech interface HTML, XML, XSLT, JSP, Javascript, ... handles presentation layer requests workflow session state window/page transitions consolidation/transformation of disparate data for presentation handles application layer requests implementation of domain rules domain services (POS, Inventory)- services may be used by just one application, but there is also the possibility of multi-application services (relatively) high-level technical services and frameworks Persistence, Security low-level technical services, utilities, and frameworks data structures, threads, math, file, DB, and network I/Omoreapp specificdependencyBusiness Infrastructure(AKA Low-level Business Services) very general low-level business services used in many business domains
View Full Document