Refresher: Lifecycle models. Lecture 22: Moving into Design. Analysis vs. Design. Refresher: different worlds. Analysis vs. Design.

Transcription

1 Analysis vs. Design Why the distinction? Design Processes Logical vs. Physical Design System vs. Detailed Design Architectures System Architecture Software Architecture Architectural Patterns (next lecture) Useful Notation UML Packages Dependencies Lecture : Moving into Design Easterbrook version 1 perceived need Refresher: Lifecycle models architecture (high level ) version Evolutionary development (each version incorporates new ) code (low level ) Waterfall model unit O&M version 3 lessons learnt lessons learnt maintain O&M analyse preliminary detailed V model code debug component Easterbrook 004 Level of abstraction Spiral model Plan alternatives 4 constraints 4 Alternatives alternatives 3 constraints 3 altern atives constr aints Constraints unit acceptance integration risk analysis 4 risk analysis 3 integration time Evaluate alternatives risks budget 4 budget 3 budget budget prototype 1 prototype 1 prototype prototype 3 4, lifecycle plan development plan integration plan implementation plan risk analysis risk analysis 1 concept of operation validated validated, verified acceptance unit code detailed Develop Analysis Analysis vs. Design Asks what is the problem? what happens in the current? what is required in the new? Results in a detailed understing of: Requirements Domain Properties Focuses on the way human activities are conducted Design Investigates how to build a solution How will the new work? How can we solve the problem that the analysis identified? Results in a solution to the problem A working that satisfies the Hardware + Software + Peopleware Focuses on building technical solutions Separate activities, but not necessarily sequential Easterbrook Application Domain Refresher: different worlds Analysis is all about studying this world Design is all about building this world But who builds the bridge? Machine Domain Easterbrook

2 Four philosophies Decomposition & Synthesis : Managing complexity Reuse Design a car by ing separately the chassis, engine, drivetrain, etc. Use existing components where possible Negotiation Stakeholder Conflicts Dialogue Process Design a car by getting each stakeholder to suggest (partial) s, them compare discuss them Search Transformation Heuristic Evaluation Design a car by transforming an initial rough to get closer closer to what is desired Situated Design Errors in existing s Evolutionary Change Design a car by observing what s wrong with existing cars as they are used, identifying improvements Easterbrook Logical vs. Physical Design Logical Design Logical Design concerns: Choose Platform Physical Design Anything that is platform-independent: Interactions between objects Layouts of user interfaces Nature of comms/data passed between subs Logical s are usually portable to different platforms Physical Design concerns: Anything that depends on the choice of platform: Distribution of objects/services over networked nodes Choice of programming language development environment Use of specialized device drivers Choice of database server technology Services provided by middleware Easterbrook System Design vs. Detailed Design System Design Choose a System Architecture Networking infrastructure Major computing platforms Roles of each node (e.g. client-server; clients-broker-servers; peer-to-peer, ) Choose a Software Architecture (see next lecture for details) Identify the subs Identify the components connectors between them Design for modularity to maximize ability evolveability E.g. Aim for low coupling high Detailed Design Decide on the formats for data storage E.g. a data management layer Design the control functions for each component E.g. an application logic layer Design the user interfaces E.g. a presentation layer Easterbrook Choices: Global System Architecture Allocates users other external s to each node Identify appropriate network topology technologies Identify appropriate computing platform for each node See next slide Easterbrook 004 8

3 System Architecture Questions Key questions for choosing platforms: What hardware resources are needed? CPU, memory size, memory bwidth, I/O, disk space, etc. What /OS resources are needed? application availability, OS scalability What networking resources are needed? network bwidth, latency, remote access. What human resources are needed? OS expertise, hardware expertise, administration, user training/help desk. What other needs are there? security, reliability, disaster recovery, uptime. Key questions constraining the choice: What funding is available? What resources are already available? Existing hardware,, networking Existing staff their expertise Existing relationships with vendors, resellers, etc. 9 Easterbrook 004 Data Management Questions How is data entry performed? E.g. Import from other s Electronic Data Interchange (EDI), Data interchange languages, What kinds of data persistence is needed? An example: client-server Servers provide some kind of service; clients request use services applications are located with clients Is the operating s basic file management sufficient? Is object persistence important? Can we isolate persistence mechanisms from the applications? E.g. running on PCs workstations; data storage is treated as a server Is a Database Management System (DBMS) needed? E.g. using a DBMS such as DB, Ingres, Sybase or Oracle Consistency checking is located with the server Is data accessed at a fine level of detail Advantages: E.g. do users need a query language? Breaks the into manageable components Makes the control data persistence mechanisms clearer Is sophisticated indexing required? Is there a need to move complex data across multiple platforms? Variants: Will a data interchange language suffice? E.g. HTML, SGML, XML Thick clients have their own services, thin ones get everything from servers Note: This is a SOFTWARE architecture Is there a need to access the data from multiple platforms? Easterbrook 004 A architecture defines: the components of the how the components use each other s functionality data How control is managed between the components bar codes; Optical Character Recognition (OCR) Software Architecture E.g. Keyless Data entry 10 Easterbrook 004 Clients server could be on the same machine or different machines 11 Easterbrook

4 Coupling Given two units (e.g. methods, classes, modules, ), A B: Form Features Desirability Data Data coupling A & B communicate communicate by by High High (use (use parameter parameter passing passing & simple simple data data only only only only pass pass necessary necessary info) info) Stamp coupling A & B use use a common common Okay Okay (but (but should should they they be be type type of of data data grouped grouped in in a data data abstraction?) abstraction?) Control coupling A transfers transfers control control to to (activating) B by by procedure procedure call Necessary call Control coupling A passes passes a flag flag to to B to to Undesirable (why (why should should A (switching) tell tell it it how how to to behave behave interfere interfere like like this?) this?) A & B make make use use of of a Undesirable (if (if you you change Common change environment shared shared data data area area the the shared shared data, data, you you have have to coupling to (global (global variables) variables) change change both both A B) B) Content coupling A changes changes B s B s data, data, or or Extremely Foolish Foolish (almost passes (almost passes control control to to the the middle middle of of B impossible impossible to to debug!) debug!) Easterbrook Cohesion How well do the contents of an object (module, package, ) go together? Form Features Desirability Data Data all all part part of of a well well defined defined data data abstraction abstraction Very High Functional all all part part of of a single single problem problem solving solving task task High outputs outputs of of one one part part form form inputs inputs to Sequential to the the next next Okay Communicational operations operations that that use use the the same same input input or or output output data data Moderate Procedural a set set of of operations operations that that must must be be executed executed in in a particular particular order order Low Low Temporal elements elements must must be be active active around around the the same same time time (e.g. (e.g. at at startup) startup) Low Low Logical Logical elements elements perform perform logically logically similar similar operations operations (e.g. (e.g. printing printing things) things) No No way!! Coincidental elements elements have have no no conceptual conceptual link link other other than than repeated repeated code code No No way!! way!! Easterbrook UML Packages Package notation We need to represent our architectures UML elements can be grouped together in packages Elements of a package may be: other packages (representing subs or modules); classes; models (e.g. use case models, interaction diagrams, statechart diagrams, etc) Each element of a UML model is owned by a single package Packages need not correspond to elements of the analysis or the they are a convenient way of grouping other elements together Criteria for decomposing a into packages: Ownership who is responsible for working on which diagrams Application each problem has its own obvious partitions; Clusters of classes with strong e.g., course, course description, instructor, student, Or use an architectural pattern to help find a suitable decomposition Easterbrook alternatives for showing package containment: Easterbrook

5 Package Diagrams Dependency Cycles Persons Meetings Constraints dependency (read as depends on ) Dependencies: Similar to compilation dependencies Captures a high-level view of coupling between packages: If you change a class in one package, you may have to change something in packages that depend on it A good architecture minimizes dependencies Fewer dependencies means lower coupling Dependency cycles are especially undesirable Easterbrook Easterbrook Architectural Patterns Presentation Layer Package E.g. 3 layer architecture: Presentation Layer Application Logic Layer Storage Layer Java AWT Storage Layer Package JDBC Application Windows Object to Relational Application Logic Layer Package Control Objects Business Objects Java SQL Easterbrook