1. Topic 10: Design Elements
Object-Oriented Systems Analysis and Design
Joey F. George, Dinesh Batra,
Joseph S. Valacich, Jeffrey A. Hoffer
© Prentice Hall, 2007

2. Chapter Objectives After studying this chapter you should be able to:
Describe the different design architecture configurations.
Understand the use of components in systems design.
Understand the different component standards.
Map an analysis class diagram into a design class diagram.
© Prentice Hall, 2007

3. © Prentice Hall, 2007

4. What Is a Design Element?
Either a design class or a component:
Design Class – an enhanced version of an analysis class that includes details regarding attributes and methods, including visibility, arguments, and data types.
Component – a replaceable part of a system that provides a clearly defined function through a set of interfaces.
© Prentice Hall, 2007

5. What Is a Design Architecture?
An overall blueprint of the design of a system.
Goal of design architecture – ability to scale and evolve over time.
Enterprise Application Design (EAD) – the process of designing applications that embrace change.
© Prentice Hall, 2007

6. What Is a Tiered (or Layered) Architecture?
The partitioning of a system into layers such that each layer performs a specific type of functionality and communicates with the layers that adjoin it.
Options
Single-tier
Two-tier
Three-tier
N-tier
© Prentice Hall, 2007

7. Single-Tier Architectures
One computer performing all tasks
Either a standalone PC, or a mainframe servicing many dumb terminals
Rare for new systems, not very scalable
© Prentice Hall, 2007

8. Two-Tier Architectures
Client-Server architecture
Client – Application layer (front-end), performs business rules and user interface
Server – Database layer (back end), provides data access
Middleware – the communication interface between client and server
© Prentice Hall, 2007

9. What Is Middleware?
Software that provides one set of interfaces for connection to a client and another set of interfaces for connection to a server, thereby providing the possibility of connections between one of several clients with one of several servers.
© Prentice Hall, 2007

10. © Prentice Hall, 2007

11. Limitations of Client-Server Architectures
Thick clients – heavy burden placed on each client machine
Application changes need to be distributed to many clients
Typically use proprietary technologies, hindering application integration
© Prentice Hall, 2007

12. Three-Tier Architectures
Three layers are:
Presentation – front tier, providing user interface, perhaps with formatting and constraint-checking rules
Business rules – middle tier, addressing logic and decisions for the system, sometimes called application layer
Data – back tier, addressing data storage and access, with some rules regarding data integrity
© Prentice Hall, 2007

13. Note: presentation, business logic, and or data can be spread across multiple layers, creating N-tier architectures.
© Prentice Hall, 2007

14. Presentation, business logic, and or data can be spread across multiple layers, creating N-tier architectures.
© Prentice Hall, 2007

15. Mapping from Analysis to Design Classes
1 Analysis Class  1 Design Class
1 Analysis Class  n Design Classes
n Analysis Classes  1 Design Class
n Analysis Classes  1 Package
n Analysis Classes  1 Component
© Prentice Hall, 2007

16. What is a Software Component?
A software element with a well-defined interface and functionality for a specific purpose that can be deployed in a variety of applications using plug-and-play capability
Invariably purchased from a third party
© Prentice Hall, 2007

17. Characteristics of Components
Used for specific commonly used purpose
Collection of classes and interfaces
Hidden implementation details
Plug-and-play capability
Usually distributed in binary, executable form
Third-party developed
Reusable in many applications
Well-tested and relatively error-free
Written in any language that supports component standard’s interface conventions
© Prentice Hall, 2007

18. Component Terminology
Run-time Environment – classes and components required to support services like handling secure transactions during run-time
Transaction – all-or-nothing unit of business work. Requires ACID:
Atomiticity, consistency, isolation, and durability
© Prentice Hall, 2007

19. What Is a Component Standard?
An agreed-upon format for defining interfaces and implementations of components
Examples:
Microsoft COM/COM+/DCOM
OMG’s CORBA
Sun Microsystem’s Enterprise Java Beans (EJB)
Database Middleware Standards (ODBC, ADO, JDBC)
XML/SOAP
© Prentice Hall, 2007

20. COM/COM+/Distrubted COM (DCOM)
Component Object Model (COM) from Microsoft
Run-time environment for middle-tier components
Supports transactions, identity, and security services, and allows components to call each other locally or remotely through a messaging service
© Prentice Hall, 2007

21. CORBA Common Object Request Broker Architecture
Published by Object Management Group (OMG)
Component standard for distributed and heterogeneous network
Objects written in different languages communicate through Interface Definition Language (IDL)
Interface is managed by Object Request Brokers (ORBs)
© Prentice Hall, 2007

22. EJB Enterprise Java Beans
Component-based distributed computing architecture
EJB is a server-side component model for managing objects in a distributed environment
EJB requires CORBA for communications
© Prentice Hall, 2007

23. Database Middleware Standards
Microsoft’s ODBC – Open Database Connectivity
Microsoft’s ADO – ActiveX Data Objects
Sun’s JDBC – Java Database Connectivity
© Prentice Hall, 2007

24. Comparison of OMG, Microsoft, and Sun
Limitations:
Tightly coupled
Binary
Proprietary
© Prentice Hall, 2007

25. XML and SOAP
Text-based, loosely coupled, non-proprietary internet-oriented standard for inter-layer communication
eXtensible Markup Language (XML) – method for putting structured data into text format, similar to HTML
Simple Object Access Protocol (SOAP) – XML-based protocol for exchanging messages between applications operating in different layers
© Prentice Hall, 2007

26. What Is a Framework?
A collection of components, consisting of code and interfaces written in a specific language, that solves or helps build applications.
Two main competitors:
Microsoft .NET
Sun Java 2 Enterprise Editiion (J2EE)
© Prentice Hall, 2007

27. Microsoft .NET
Development framework that integrates COM+ and Active Server Pages (ASP) technologies for B2C applications, with support for XML/SOAP Web services for B2B applications
ActiveX – OLE/COM based component
ADO, ADO .NET – database middleware
ASP, ASP.NET – dynamic HTML generation
© Prentice Hall, 2007

28. Features of Microsoft .NET Framework
Visual Studio .NET – development environment
C#, Visual C++, and Visual Basic .NET – the three main programming languages for developint .NET applications
Common Language Runtime (CLR) – the runtime environment that loads/executes code, manages memory, provides security, exception handling and interoperability
© Prentice Hall, 2007

29. Sun J2EE Java 2 Enterprise Edition
Development framework that provides a specification of architectural components designed to work together to define a complete enterprise architecture, with support for XML/SOAP and Web services
EJB – Java-based component standard
JDBC – database middleware
Java Server Pages, Servlets – dynamic HTML generation
© Prentice Hall, 2007

30. Features of Java J2EE
Java Virtual Machine (JVM) – interpreter for executing Java compiled code (bytecode)
Remote Method Invocation (RMI) – middleware that allows Java programs running on different computers to access each others’ objects/methods
Applet – Java program that runs in the browser as part of a web page
Servlet – Java program executed on a Web server
Java Server Pages (JSP) – technology that mixed Java and HTML for dynamic web page generation
© Prentice Hall, 2007

31. © Prentice Hall, 2007

32. Browser-Based Scripting
Logic executed at the browser layer (presentation)
Enhances HTML with interactive functionality
Two main scripting languages:
JavaScript
VBScript
© Prentice Hall, 2007

33. © Prentice Hall, 2007

34. What is a Package?
A general-purpose mechanism for organizing design elements into groups
Package diagram – a diagram that shows the packages and the relationships between them
© Prentice Hall, 2007

35. Characteristics of Packages
Cohesiveness
Allocation of resources among development teams
User types
Propensity to change
Development phase
Separate utilities from system-specific components
© Prentice Hall, 2007

36. In UML, packages are represented as rectangles with tabs in the top left corner. Dependencies between packages are shown with dashed arrow lines.
© Prentice Hall, 2007

37. What Is a Design Class Diagram?
A design class diagram shows the data types of the attributes, the return types and arguments of the operations, and the visibility specifications for all attributes and operations.
Signature – the return type, name, and argument list of a method
Interfaces to classes are based on signatures.
© Prentice Hall, 2007

38. Verifying Responsibility Allocation
Pattern – a named description of a problem and solution that can be applied to new contexts
Responsibility assignment in patterns:
Information expertise (expert pattern)
Object creation (creator pattern)
Loose coupling and strong cohesion
© Prentice Hall, 2007

39. Visibility
The characteristics of an attribute or an operation that reveal whether it can be accessed directly
Three levels of visibility:
Public – visible to any requesting object
Private – visible to the owning object only
Protected – visible to the owning object, objects of the same class, and objects of subclasses
© Prentice Hall, 2007

40. Attribute Types
In Design class diagram, attribute types are explicitly displayed
In the following slide, you see:
Visibility of attributes and operations
Attribute types
Responsibilities represented by methods
Full method signatures including return types and parameters
© Prentice Hall, 2007

41. Visibility is shown by minus signs (private) or plus signs (public)
Attribute types and full signatures are shown
© Prentice Hall, 2007

42. © Prentice Hall, 2007

43. Recap After studying this chapter we learned to:
Design the different design architecture configurations.
Understand the use of components in systems design.
Understand the different component standards.
Map an analysis class diagram into a design class diagram.
© Prentice Hall, 2007