DOC PREVIEW
UT Dallas CS 6359 - Chapters_12_14

This preview shows page 1-2-3-27-28-29 out of 29 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 29 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 29 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 29 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 29 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 29 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 29 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 29 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

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

UT Dallas CS 6359 - Chapters_12_14

Documents in this Course
Lecture2

Lecture2

63 pages

Lecture3

Lecture3

49 pages

Lecture4

Lecture4

48 pages

Lecture5

Lecture5

47 pages

Lecture6

Lecture6

45 pages

Lecture7

Lecture7

63 pages

Lecture8

Lecture8

77 pages

Lecture9

Lecture9

48 pages

Lecture10

Lecture10

84 pages

Lecture11

Lecture11

45 pages

Lecture12

Lecture12

134 pages

Lecture13

Lecture13

62 pages

Lecture14

Lecture14

76 pages

Project

Project

2 pages

Chapter_1

Chapter_1

25 pages

Load more
Download Chapters_12_14
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Chapters_12_14 and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Chapters_12_14 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?