OOSAD-Object Oriented Systems Analysis and Design - Chapter06-Part I.pptx
- 1. Object Oriented Systems Analysis and Design SOEng2052
- 2. SOEng2052 Chapter 6 – Part I Determining How to Build Your System: OO Design
- 3. SOEng2052 3 What it is? • Designing of object oriented software requires – the definition of a multilayered software architecture, – the specification of subsystems that perform required functions and provide infrastructure support, – a description of objects (classes) that form the building blocks of the system, and – a description of the communication mechanisms that allow data to flow between layers, subsystems, and objects.
- 4. SOEng2052 4 Cont… The input for object-oriented design is provided by the output of object-oriented analysis. Some typical input artifacts for object-oriented design are; Conceptual model, Use case, Sequences Diagram and User interface.
- 5. SOEng2052 5 Object-Oriented Analysis and Design Analysis Design Construction Investigation of problem Logical solution Code
- 6. SOEng2052 6 Thus Design is defined as a meaningful engineering representation of something that is to be built. both “the process of defining the architecture, components, interfaces, and other characteristics of a system or component” and “the result of that process.” As a process, software design is the software engineering life cycle activity in which software requirements are analyzed in order to produce a description of the software’s internal structure that will serve as the basis for its construction.
- 7. SOEng2052 7 Cont… More precisely, a software design (the result) must describe The software architecture how software is decomposed and organized into components and the interfaces between those components. It must also describe the components at a level of detail that enable their construction. In the software engineering context, design focuses on four major areas of concern: data, architecture, interfaces, and components.
- 8. SOEng2052 8 How do I ensure that I’ve done it right? At each stage, software design work products are reviewed for Clarity, Correctness, Completeness, and Consistency with the requirements and with one another.
- 9. SOEng2052 9 The software design process Software design is an iterative process through which requirements are translated into a “blueprint” for constructing the software. is generally considered a two-step process: Architectural design describes how software is decomposed and organized into components (the software architecture) Class type architecture, Component, Deployment, persistent diagrams Detailed design describes the specific behavior of these components. Refined class model, Statechart, collaboration
- 10. SOEng2052 10 Software Design Principles The design should be traceable to the analysis model. The design should not reinvent the wheel. The design should “minimize the intellectual distance” between the software and the problem as it exists in the real world. The design should exhibit uniformity and integration. The design should be structured to accommodate change.
- 11. SOEng2052 11 Cont… The design should be structured to degrade gently, even when aberrant data, events, or operating conditions are encountered. Design is not coding, coding is not design. The design should be assessed for quality as it is being created, not after the fact. The design should be reviewed to minimize conceptual (semantic) errors.
- 12. SOEng2052 12 Thus What to design? Some examples are… Process and association User Interfaces Storage Networking/Distribution Each requires the addition of extra classes and associations.
- 13. SOEng2052 13 Software Architecture Software architecture is the process of designing the global organization of a software system, including: Dividing software into subsystems. Deciding how these will interact. Determining their interfaces. The architecture is the core of the design, so all software engineers need to understand it. The architecture will often constrain the overall efficiency, reusability and maintainability of the system.
- 14. SOEng2052 14 The importance of software architecture Why you need to develop an architectural model? To enable everyone to better understand the system To allow people to work on individual pieces of the system in isolation To prepare for extension of the system To facilitate reuse and reusability
- 15. SOEng2052 15 Contents of a good architectural model A system’s architecture will often be expressed in terms of several different views The logical breakdown into subsystems The interfaces among the subsystems The dynamics of the interaction among components at run time The data that will be shared among the subsystems The components that will exist at run time, and the machines or devices on which they will be located
- 16. SOEng2052 16 Describing an architecture using UML All UML diagrams can be useful to describe aspects of the architectural model Some UML diagrams are particularly suitable for architecture modelling and for implementation issues: Class Type architecture (not in UML) Component diagrams Deployment diagrams Persistent diagram Package/subsystem diagram
- 17. SOEng2052 17 Design Tasks and Models Software design consists of: Class Type Architecture (not in UML) Class diagrams State chart diagrams Collaboration diagrams Component models Deployment diagrams Persistent diagram Evolving UI
- 18. SOEng2052 18 Class Type Architecture (not in UML) A common architectural strategy, some might call it a pattern, is to layer the architecture of a system into several layers/strata. The various layers are represented by the rectangles and collaboration between layers by the arrows. The primary name of a layer is indicated first, and other common names in parenthesis
- 19. SOEng2052 19 Layered class type architecture
- 20. 20 Cont… Interface: There are two categories of interface class – user interface (UI) classes that provide people access to your system and system interface (SI) classes that provide access to external systems to your system Domain This layer implements the concepts pertinent to your business domain such as Student or Seminar, focusing on the data aspects of the business objects, plus behaviors specific to individual objects SOEng2052
- 21. SOEng2052 21 Cont… Process The process layer implements business logic that involves collaborating with several domain classes or even other process classes Persistence Persistence layers encapsulate the capability to store, retrieve, and delete objects/data permanently without revealing details of the underlying storage technology. often implement between your object schema and your database schema and there are various available to you. System System classes provide operating-system-specific functionality for your applications, isolating your software from the operating system (OS) by wrapping OS-specific features, increasing the portability of your application
- 22. SOEng2052 22 Class Modeling The class model at the design level will add some additional details than that of the analysis level class model. Here the focus will be the solution domain rather than the problem domain. In practice, the analysis level class model will evolve into a design level class model.
- 23. SOEng2052 23 Cont… There will be changes to be introduced to the analysis class model based on implementation technologies. This gives the developers the chance to make amendments and modification to improve the quality of the system. Changes will also be forced into the class model due to the implementation technology to be used.
- 24. SOEng2052 24 Cont… The design level class model will concentrate on how to implement attributes, methods, inheritance, association, aggregation, composition and the likes. Modeling Methods Methods, also called operations or member functions, are the object-oriented equivalent of functions and procedures. The design level will model more information about methods than the analysis.
- 25. SOEng2052 25 Cont… The design level may include: Visibility: the level of access that external objects have to a method. To reduce the effect of coupling within a system, more restrictions on access of methods should be set. In other words, if a method does not have to be public then make it protected and if it does not have to be protected then make it private.
- 26. SOEng2052 26 Cont… Visibility Symbol Description Proper Usage Public + A public method can be invoked by any other method in any other object or class. When the method must be accessible by objects and classes outside of the class hierarchy in which the method is defined. Protected # A protected method can be invoked by any method in the class in which it is defined or any subclasses of that class. When the method provides behavior needed internally within the class hierarchy, but not externally. Private - A private method can only be invoked by other methods in the class in which it is defined, but not in the subclasses. When the method provides behavior specific to the class. Private methods are often the result of refactoring.
- 27. SOEng2052 27 Cont… The design level may include: Name: Descriptive name for the method. A good name is the one that is capable of explaining the purpose of the methods just by looking at its name. In giving a name to methods the designer needs to know what programming language will be used for the development so that the naming convention of that language will be used here. Parameters: The names of parameters, and optionally their types and default values (if any); Return value type: The data type of the return value (if available)
- 28. SOEng2052 28 Cont… Modeling Attributes Attributes are the data aspects of objects. The design level will model more information about methods than the analysis. The design level may include: Visibility: This is the level of access external objects have to an attribute.
- 29. SOEng2052 29 Cont… Visibility Symbol Description Public + A public attribute can be accessed by any other method in any other object or class. Protected # A protected attribute can be accessed by any method in the class in which it is declared or by any method defined in subclasses of that class. Private - A private attribute can only be accessed by method in the class in which it is declared, but not in the subclasses.
- 30. SOEng2052 30 Cont… Name: descriptive name to attributes. A good attribute name is the one that is capable of explaining the purpose of the attribute just by looking at its name. Attributes that are collections, such as arrays, should be given names that are plural to indicate they represent multiple values, the rest should be singular.
- 31. SOEng2052 31 Cont… In giving a name to attributes the designer needs to know what programming language will be used for the development so that the naming convention of that language will be used here. The most important technique for designing and using attributes effectively is not to access them directly in your code.
- 32. SOEng2052 32 Cont… Following are some of the recommendations: Assign private visibility to all attributes; Update attributes only in their setter methods; Directly access attributes only in their getter methods; Enforce simple validation logic for an attribute in its setter method; Implement complex validation logic in separate methods; and Apply initialization in getter methods for attributes
- 33. SOEng2052 33 Cont… Type: The data type of an attribute should be determined (could be a primitive type, such as string or int, or a class such as Address.) Initial value: The initial value for an attribute should also be indicated (if available).
- 34. SOEng2052 34 Cont… Modeling Association Objects in any system cannot exist and work alone. For this reason they need to depend on one another or collaborate with each other. The dependency and collaboration will help the development team to define how they interact with each other. The collaboration is important as an object needs to know about another object to work with it. For each association multiplicity should be modeled, one on each end of the association line
- 35. SOEng2052 35 In Design Minimize coupling and Maximize cohesion Coupling is a measure of how much two items, such as classes or methods, are interrelated. When one class depends on another class, we say they are coupled. When one class interacts with another class, but does not know any of the implementation details of the other class, we say they are loosely coupled. A class is coupled to another class when it has knowledge of that other class. Coupling is important because when Class A is coupled to Class B, a change in B could necessitate a change in A.
- 36. SOEng2052 36 Cont… Cohesion is a measure of how much an item, such as a class or method, makes sense. A good measure of the cohesiveness of something is how long describing it takes using only one sentence: the longer it takes, the less cohesive it likely is. You want to design methods and classes that are highly cohesive.
- 37. SOEng2052 37 Cont… In other words, it should be completely clear what a method or class is all about. A good rule of thumb is if you cannot describe a class or method with one sentence in less than 15 seconds, then it probably is not cohesive. Classes should represent only one kind of object, and methods should do one thing and one thing well.
- 38. SOEng2052 38 Following is an example to compare Analysis and design versions of a class Analysis Level Design Level
Editor's Notes
- #10: Tunnel vision A good designer should consider alternative approaches, judging each based on the requirements of the problem, the resources available to do the job, and the design concepts. Traceability Because a single element of the design model often traces to multiple requirements Don’t reinvent Time is short and resources are limited! previously used design patterns and integrating with new ones Uniformity and integration A design is uniform if it appears that one person developed the entire thing. Rules of style and format should be defined for a design team before design work begins. A design is integrated if care is taken in defining interfaces between design components. Design ≠ Coding Even when detailed procedural designs are created for program components, the level of abstraction of the design model is higher than source code. Design quality A variety of design concepts and design measures are available to assist the designer in assessing quality. Conceptual/Semantic errors There is sometimes a tendency to focus on minutiae when the design is reviewed, missing the forest for the trees. A design team should ensure that major conceptual elements of the design (omissions, ambiguity, inconsistency) have been addressed before worrying about the syntax of the design model. When these design principles are properly applied, the software engineer creates a design that exhibits both external and internal quality factors. External quality factors are those properties of the software that can be readily observed by users (e.g., speed, reliability, correctness, usability). Internal quality factors are of importance to software engineers. They lead to a high-quality design from the technical perspective. To achieve internal quality factors, the designer must understand basic design concepts and principles.