Topic : Object Oriented Design Principles Software Engineering Faculty of Computing Universiti Teknologi Malaysia
Objectives Describe the differences between requirements activities and design activities Explain the purpose of design and the difference between architectural and detailed design activities Describe 3 architectural styles Describe detailed design activities 2 Object-Oriented Analysis and Design with the Unified
Comparison of Modeling During the Business Modeling, Requirements, and Design Disciplines 3 Object-Oriented Analysis and Design with the Unified
4 UML Diagrams
Understanding the Elements of Design Systems design discipline Describe, organize, and structure system components Artifacts at architectural level and detailed level Purpose: enable system construction and deployment Two tiers of discipline tasks High (architectural) Hardware and system software infrastructure Low(detail design) Small modules such as software design for a use case 5 Object-Oriented Analysis and Design with the Unified
Design Discipline Activities Segmented into 6 major activities Design the support services architecture and deployment environment (networking class) Design the software architecture focus of SE lecture Design use case realizations focus of SE lecture Design the database (database class) Design the system and user interfaces (HCI class) Design the system security and controls (network security; database security) 6 Object-Oriented Analysis and Design with the Unified
Design the Software Architecture Software architecture refers to the big picture Two important aspects Division of software into classes Distribution of classes across processing locations Modify class diagrams into software classes Determine where classes and objects execute Determine whether they will be distributed Determine communication methods Select programming language(s) to write classes 7 Object-Oriented Analysis and Design with the Unified
Design Use Case Realizations Use case realizations offer a lower-level view Two-tiered focus Class interactions supporting a particular use case Interactions among software, users, and external systems Design typically spread over many iterations UML design class diagrams and interaction diagrams document design 8 Object-Oriented Analysis and Design with the Unified
9 Object-Oriented Analysis and Design with the Unified Process Design software architecture (high level design) Client server architecture Layered architecture Repository architecture
2016 Software Engineering 10 Definitions Architectural design : The design process for identifying the subsystems making up a system and the framework for sub-system control and communication. The output of this design process is a description of the software architecture.
2016 Software Engineering 11 Architectural Design An early stage of the system design process. Represents the link between specification and design processes. Often carried out in parallel with some specification activities. It involves identifying major system components and their communications.
2016 Software Engineering 12 Architecture Analogy for Software vs. House?
2016 Software Engineering 13 Architecture Style Client Server Repository Layered
Client/Server Architecture Client/server architecture tiers Client: requests resources or services from a server Server: manages information system resources Architectural issues for client/server software: Decomposing software into client and server programs (objects) Determining where clients and servers will execute Describing interconnection protocols and networks 14 Object-Oriented Analysis and Design with the Unified
2016 Software Engineering 15 Client-Server Architecture Distributed system model which shows how data and processing is distributed across a range of components. Can be implemented on a single computer. Set of stand-alone servers which provide specific services such as printing, data management, etc. Set of clients which call on these services. Network which allows clients to access servers. Used when data in a shared database has to be accessed from a range of locations.
Client/Server Architecture Client/Server Architecture with a Shared Database 16 Object-Oriented Analysis and Design with the Unified
Client/Server Architecture (continued) Client and server communicate via welldefined protocols over a physical network Client/server architecture advantages Location flexibility, scalability, maintainability Client/server architecture disadvantages Additional complexity, potential poor performance, security issues, and reliability 17 Object-Oriented Analysis and Design with the Unified
2016 Software Engineering 18 Pros and Cons Advantages Servers can be distributed across a network. Disadvantages Each service is a single point of failure so susceptible to denial of service attacks or server failure. General functionality (e.g. a printing service) can be available to all clients and does not need to be implemented by all services. Performance may be unpredictable because it depends on the network as well as the system.
Interaction Among Multiple Clients and a Single Server 19 Object-Oriented Analysis and Design with the Unified
2016 Software Engineering 20 Repository Architecture Sub-systems must exchange data. This may be done in two ways: Shared data is held in a central database or repository and may be accessed by all sub-systems; Each sub-system maintains its own database and passes data explicitly to other sub-systems. When to use: large amounts of data are to be shared and stored for a long time. in data-driven systems where the inclusion of data in the repository triggers an action or tool
2016 Software Engineering 21 Pros and Cons Advantages Components can be independent. Disadvantages Problems in the repository affect the whole system. Changes made by one component can be propagated to all components. All data can be managed consistently (e.g. backups done at the same time) Inefficiencies in organizing all communication through the repository. Difficulties in distributing the repository across several computers
2016 Software Engineering 22 A Repository Architecture for an IDE
Layered Architecture Variant of client/server architecture Divides application software into independent processes Three-layers The data layer The business logic layer The view (presentation) layer Three-tier architecture advantages Additional flexibility and reliability 23 Object-Oriented Analysis and Design with the Unified
2016 Software Engineering 24 Layered Model Used when: building new facilities on top of existing systems the development is spread across several teams with each team responsibility for a layer of functionality there is a requirement for multi-level security security is a critical requirement Example: Layered security architecture, a system to provide file security
2016 Software Engineering 25 Pros and Cons Advantages: Each layer can be considered to be an increasing level of abstraction Designers can use the layers to decompose a problem into a sequence of more abstract steps It s easy to add or modify a layer as the need arises Disadvantages: Not easy to structure a system in layers The multiple layers of abstraction are not always evident when examine a set of requirements System performance may suffer from the extra coordination among the layers
Three-layer Architecture 26 Object-Oriented Analysis and Design with the Unified
2016 Software Engineering 27 A Client-Server Architecture for a Film Library
2016 Software Engineering 28 The Architecture of the LIBSYS System
2016 Software Engineering 29 COMPONENT DIAGRAMS AND ARCHITECTURAL DESIGN
Object oriented component notation 30 Object-Oriented Analysis and Design with the Unified Process
Extension notation for windows and web page 2016 Software Engineering 31
Two-Layer Architectural Design of Internet Systems 2016 Software Engineering 32
Three-Layer Architectural Design of Internet Systems 2016 Software Engineering 33
34 Object-Oriented Analysis and Design with the Unified Process Principles of object oriented detailed design(low level design) Design class diagram Design class symbol Fundamental detailed design principles
DESIGN CLASS DIAGRAM 2016 Software Engineering 35
Design class diagram 2016 Software Engineering 36
Java Program vs Class Diagram 37 Object-Oriented Analysis and Design and the Unified Process
DESIGN CLASS SYMBOL 2016 Software Engineering 38
39 Object-Oriented Analysis and Design and the Unified Process Design Class Symbols Stereotypes UML notation to categorize a model element as a certain type Two types of notation Full notation with guillemets () Shorthand notation with circular icons Standard stereotypes Entity, control, boundary, data access
40 Object-Oriented Analysis and Design and the Unified Process Full notation Shorthand notation Standard stereotypes found in design models
2016 Software Engineering 41 Boundary Class Reference from Center of Advanced Software Engineering (CASE)
2016 Software Engineering 42 Example Boundary Class Reference from Center of Advanced Software Engineering (CASE)
2016 Software Engineering 43 Entity Class Reference from Center of Advanced Software Engineering (CASE)
2016 Software Engineering 44 Example Entity Class Reference from Center of Advanced Software Engineering (CASE)
2016 Software Engineering 45 Control class Reference from Center of Advanced Software Engineering (CASE)
2016 Software Engineering 46 Example control class Reference from Center of Advanced Software Engineering (CASE)
47 Object-Oriented Analysis and Design and the Unified Process Design Class Notation Class name and stereotype information Attribute information Visibility, type-expression, name, initial value, and properties Method signature Visibility, name, type-expression, and parameter list Use the entire signature to identify a method to distinguish between overloaded methods
Internal Symbols and Example 48 Object-Oriented Analysis and Design and the Unified Process
Notation for Design Classes method arguments and return types not shown Systems Analysis and Design in a Changing World, 6th Edition 49
Systems Analysis and Design in a Changing World, 6th Edition 50 Navigation Visibility The ability of one object to view and interact with another object Accomplished by adding an object reference variable to a class. Shown as an arrow head on the association line customer can find and interact with sale because it has mysale reference variable
Systems Analysis and Design in a Changing World, 6th Edition 51 Navigation Visibility Guidelines One-to-many associations that indicate a superior/subordinate relationship are usually navigated from the superior to the subordinate Mandatory associations, in which objects in one class can t exist without objects of another class, are usually navigated from the more independent class to the dependent When an object needs information from another object, a navigation arrow might be required Navigation arrows may be bidirectional.
Systems Analysis and Design in a Changing World, 6th Edition 52 First Cut Design Class Diagram Proceed use case by use case, adding to the diagram Pick the domain classes that are involved in the use case (see preconditions and post conditions for ideas) Add a controller class to be in charge of the use case Determine the initial navigation visibility requirements using the guidelines and add to diagram Elaborate the attributes of each class with visibility and type Note that often the associations and multiplicity are removed from the design class diagram as in text to emphasize navigation, but they are often left on
Systems Analysis and Design in a Changing World, 6th Edition 53 Start with Domain Class Diagram RMO Sales Subsystem
Systems Analysis and Design in a Changing World, 6th Edition 54 Create First Cut Design Class Diagram Use Case Create phone sale with controller added
55 Object-Oriented Analysis and Design and the Unified Process Developing the First-Cut Design Class Diagram Elaborate the attributes with type and initial value information Most attributes should be private Add navigation visibility arrows Based on which classes need access to which other classes Can be bidirectional Will need to be updated as design progresses
Final DCD for the Process new order use case Systems Analysis and Design in a Changing World, 6th Edition 56
2016 Software Engineering 57 FUNDAMENTAL DETAILED DESIGN PRINCIPLES
58 Object-Oriented Analysis and Design and the Unified Process Some Fundamental Design Principles Encapsulation Each object is a self-contained unit containing both data and program logic Object reuse Standard objects can be used over and over again within a system Information hiding Data associated with an object is not visible Methods provide access to data
59 Object-Oriented Analysis and Design and the Unified Process Some Fundamental Design Principles (continued) Navigation visibility Describes which objects can interact with each other Coupling Measures how closely classes are linked. Objects which send messages to one another have navigation visibility and thus are coupled. Lower navigation visibility lower coupling Cohesion Measures the consistency of functions in a class Cohesion is where the Classes perform one specific function Classes which perform too much functions (low cohesion) hard to be reused; difficult to understand and hard to maintain. Separation of responsibilities Divides a class into several highly cohesive classes
2016 Software Engineering 60 EXTRA SLIDES ON COHESION AND COUPLING
Cohesion 61
Coupling 62
Cohesion and Coupling 63
2016 Software Engineering 64 Key Points A software architecture is a high level design to describe of how a software system is organized. Architectural style are a means of reusing knowledge about generic system architectures. They describe the architecture, explain when it may be used and describe its advantages and disadvantages. Model involved in software architecture is component diagram. Object oriented detailed design is a low level design where the identification and description of sets of objects that must work together to carry put each use case is done. Models involved in detailed design are class diagram and sequence diagram (will be elaborated in object oriented design use case realizations lecture)
2016 Software Engineering 65 Key Points Models of application systems architectures help us understand and compare applications, validate application system designs and assess large-scale components for reuse. Transaction processing systems are interactive systems that allow information in a database to be remotely accessed and modified by a number of users. Language processing systems are used to translate texts from one language into another and to carry out the instructions specified in the input language. They include a translator and an abstract machine that executes the generated language.