Presentation is loading. Please wait.

Presentation is loading. Please wait.

The Design Discipline.

Similar presentations

Presentation on theme: "The Design Discipline."— Presentation transcript:

1 The Design Discipline

2 Moving From Business Modeling Requirements to Design
Figure 7-1

3 Understanding the Elements of Design
Systems design discipline Two tiers of discipline tasks Design Activities Support services architecture & deployment environment Software architecture Use case realizations Database System and user interfaces System security and controls

4 System Development Information Stored in the CASE Repository
Figure 7-3 System Development Information Stored in the CASE Repository

5 Deployment Environment (Support services architecture & deployment environment)
Single-Computer and Multitier Architecture Centralized and Distributed Architecture Computer Networks Internet, intranets, and extranets

6 Client/Server Architecture (Software architecture)
Client/server architecture tiers Architectural issues for client/server software Client and server communicate via well-defined protocols over a physical network Client/server architecture advantages Client/server architecture disadvantages

7 Client/Server Architecture with a Shared Database
Figure 7-9 Client/Server Architecture with a Shared Database

8 Interaction Among Multiple Clients and a Single Server
Figure 7-11 Interaction Among Multiple Clients and a Single Server

9 Three-Layer Client/Server Architecture
Variant of client/server architecture Three-layers The data layer The business logic layer The view (presentation) layer Three-tier architecture advantages

10 Three-layer Architecture
Figure 7-12 Three-layer Architecture

11 Internet and Web-Based Software Architecture
Web is complex example of client/server architecture Advantages Disadvantages of Web technologies The key architectural design issues Defining client and server processes or objects Distributing processes across hardware platforms Connecting processes

12 What is Object-Oriented Design?
The bridge between a user’s requirements and programming for the new system An adaptive approach to development Requirements and design are done incrementally within an iteration A complete set of designs may not be developed at one time

13 Overview of Object-Oriented Programs
Object-oriented programs consist of a set of computing objects that cooperate to accomplish a result Most object-oriented programs are event-driven Instantiation of a class creates an object based on the template provided by the class definition

14 Object-oriented event-driven program flow
Figure 8-1 Object-oriented event-driven program flow

15 Object-Oriented Design Models
Identify all objects that must work together to carry out a use case Divide objects into groups for a multilayer design Interaction diagrams describe the messages that are sent between objects Design class diagrams document and describe the programming classes Statecharts capture information about the valid states and transitions of an object Package diagrams denote which classes work together as a subsystem

16 Design models with their respective input models
Figure 8-4 Design models with their respective input models

17 Design Classes and Design Class Diagrams
Design class diagrams are extensions of domain class model diagrams Elaborate on attribute details Define parameters and return values of methods Determine stereotypes A first-cut design class diagram is based on the domain model and engineering design principles Interaction diagrams are used to refine a design class diagram as development progresses

18 Figure 8-7 Student class examples for the domain diagram and the design class diagram

19 Some Fundamental Design Principles
Encapsulation Object reuse Information hiding Navigation visibility Coupling Cohesion Separation of responsibilities

20 Figure 8-10 First-cut RMO design class diagram

21 Interaction Diagrams–Realizing Use Cases and Defining Methods
Interaction diagrams are at the heart of object-oriented design Realization of a use case Determine what objects collaborate by sending messages to each other Object Responsibility Knowing Doing

22 Use Case Controller An artifact invented by the designer to handle a system function Serves as a collection point for incoming messages Intermediary between the outside world and the internal system A single use case controller results in low cohesion Several use case controllers raise coupling but result in high cohesion

23 SSD for the Look up item availability use case
Recall a SSD Figure 8-12 SSD for the Look up item availability use case

24 First-Cut Sequence Diagram
Determine which other objects may need to be involved to carry out the use case Replace the :System object with a use case controller object Determine all of the internal messages that result from each input message Identify the complete set of classes that will be affected by each message Flesh out the components for each message Iteration, true/false conditions, return values, and passed parameters

25 First-cut sequence diagram for the Look up item availability use case
Figure 8-14 First-cut sequence diagram for the Look up item availability use case

26 Developing a Multilayer Design
View layer Design the user interface for each use case Develop dialog designs for forms Add the window classes to the sequence diagram Data access layer Initialize domain objects with data from the database Query the database and send a reference object Return information in the reference object

27 Figure 8-17 Completed three-layer design for Look up item availability

28 Updating the Design Class Diagram
Add classes for the view and data access layers Update classes with method signatures Constructor and get and set methods are optional Use case specific methods are required Every message in a sequence diagram requires a method in the destination object Include the new user controller classes and add navigation arrows

29 Figure 8-30 Updated design class diagram for the domain layer

30 Package Diagrams-Structuring the Major Components
Associates classes of related groups One option is to separate the view, domain, and data access layers into separate packages Indicate dependency relationships Shows which elements affect other elements in a system May exist between packages, or between classes within packages Packages can be nested

31 Partial design for a three-layer package diagram for RMO
Figure 8-31 Partial design for a three-layer package diagram for RMO

32 Implementation Issues for Three-Layer Design
IDE tools can help programmers construct systems IDE tools can also make a system difficult to maintain Creates window classes that generate class definitions Inserts business logic code into the user interface Use good design principles when developing a system Define object responsibility for each layer

33 Summary Design is driven by use cases
Two primary models developed during design Design class diagrams Sequence class diagrams Multilayer designs partition classes into groups View, domain, and data access layers Communication diagrams are a viable alternative to sequence diagrams

34 Summary (continued) Object-oriented design principles
Encapsulation Coupling Cohesion Navigation Object responsibility Package diagrams can group classes by subsystem or layer

Download ppt "The Design Discipline."

Similar presentations

Ads by Google