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