Ad
More Related Content
Similar to software engineering unit-3 in software engineering (20)
Recently uploaded (20)
Ad
software engineering unit-3 in software engineering
- 1. MALLA REDDY INSTITUTE OF TECHNOLOGY AND SCIENCE CS502PC: SOFTWARE ENGINEERING III YEAR B.TECH. CSE/IT I - SEM (JNTUH-R18) UNIT-III
- 2. ๏ต Design Engineering : Design process and Design quality, Design concepts, the design model. ๏ต Creating an architectural design : Software architecture, Data design, Architectural styles and patterns, Architectural Design, conceptual model of UML, basic structural modeling, class diagrams, sequence diagrams, collaboration diagrams, use case diagrams, component diagrams.
- 3. Design Engineering ๏ตDesign engineering encompasses the set of principles, concepts, and practices that leads to the development of a high- quality system or product. What is design? ๏ตDesign is what virtually every engineer wants to do. ๏ตIt is the place where creativity rules โ customerโs requirements, business needs, and technical considerations all come together in the formulation of a product or a system. Why is it important? ๏ตDesign allows a software engineer to model the system or product that is to be built. ๏ตDesign is the place where software quality is established.
- 4. DESIGN PROCESS AND DESIGN QUALITY: Software design is an iterative process through which requirements are translated into a โblueprintโ for constructing the software. Goals of design: ๏ตThe design must implement all of the explicit requirements contained in the analysis model . ๏ตThe design must be a readable, understandable guide. ๏ตThe design should provide a complete picture of the software Quality guidelines: ๏ตA design should exhibit an architecture that , ๏ต a. has been created using recognizable architectural styles or patterns ๏ต b. is composed of components that exhibit good design characteristics and ๏ต c. can be implemented in an evolutionary fashion, thereby facilitating implementation and testing. ๏ตA design should be modular. ๏ตA design should contain distinct representation of data, architecture, interfaces and components.
- 5. ๏ต lead to data structures that are appropriate for the classes to be implemented . ๏ต lead to components that exhibit independent functional characteristics. ๏ต lead to interface that reduce the complexity of connections between components and with the external environment. ๏ต should be derived using a repeatable method that is driven by information obtained during software requirements analysis. ๏ต should be represented using a notation that effectively communicates its meaning. Quality attributes: (FURPS) ๏ต Functionality ๏ต Usability ๏ต Reliability ๏ต Performance ๏ต Supportability
- 6. DESIGN CONCEPTS: Fundamental software design concepts provide the necessary framework for โgetting it right.โ 1. Abstraction: Many levels of abstraction are there, ๏ต At the highest level of abstraction, a solution is stated in broad terms using the language of the problem environment. ๏ต At lower levels of abstraction, a more detailed description of the solution is provided. ๏ต A procedural abstraction refers to a sequence of instructions that have a specific and limited function. ๏ต A data abstraction is a named collection of data that describes a data object.
- 7. 2. Architecture: ๏ตthe overall structure of the software and the ways in which that structure provides conceptual integrity for a system ๏ต Structured models - organized collection of program components. ๏ต Framework models - increase the level of design abstraction. ๏ต Dynamic models - address the behavioral aspects of the program architecture, indicating how the structure or system configuration may change as a function external events. ๏ต Process models - focus on the design of the business or technical process that the system must accommodate. ๏ต Functional models - can be used to represent the functional hierarchy of a system.
- 8. 3. Patterns: ๏ตa design pattern describes a design structure that solves a particular design within a specific context and amid โforcesโ that may have an impact on the manner in which the pattern is applied and used. ๏ตThe intent of each design pattern is to provide a description that enables a designer to determine 1) Whether the pattern is capable to the current work, 2) Whether the pattern can be reused, 3) Whether the pattern can serve as a guide for developing a similar, but functionally or structurally different pattern.
- 9. 4. Modularity ๏ตsoftware is divided into separately named and addressable components, sometimes called modules that are integrated to satisfy problem requirements. 5. Information Hiding: ๏ตinformation contained within a module is inaccessible to other modules that have no need for such information. 6. Functional Independence: ๏ตdirect outgrowth of modularity and the concepts of abstraction and information hiding. ๏ตIndependence is assessed using two qualitative criteria: cohesion and coupling. ๏ต Cohesion is an indication of the relative functional strength of a module. ๏ต Coupling is an indication of the relative interdependence among modules.
- 10. 7. Refinement: ๏ตA program is development by successively refining levels of procedural detail. ๏ตRefinement is actually a process of elaboration. 8. Refactoring: ๏ตRefactoring is a reorganization technique that simplifies the design of a component without changing its function or behavior. 9. Design classes: ๏ตThe software team must define a set of design classes that , ๏ต 1. Refine the analysis classes by providing design detail that will enable the classes to be implemented, and ๏ต 2. Create a new set of design classes that implement a software infrastructure to support the design solution.
- 11. Five different types of design classes , ๏ตUser interface classes: define all abstractions that are necessary for human computer interaction. ๏ตBusiness domain classes: are often refinements of the analysis classes defined earlier. ๏ตProcess classes implement lower โ level business abstractions required to fully manage the business domain classes. ๏ตPersistent classes represent data stores that will persist beyond the execution of the software. ๏ตSystem classes implement software management and control functions that enable the system to operate and communicate within its computing environment and with the outside world. Four characteristics of a well- formed design class, ๏ต Complete and sufficient ๏ต Primitiveness ๏ต High cohesion ๏ต Low coupling
- 13. i. Data design elements: ๏ตcreates a model of data and/or information that is represented at a high level of abstraction. ๏ตThe structure of data has always been an important part of software design. ๏ต At the program component level ๏ต At the application level ๏ต At the business level ii. Architectural design elements: ๏ตThe architectural design for software is the equivalent to the floor plan of a house. The architectural model is derived from three sources. ๏ต a. Information about the application domain for the software to be built. ๏ต b. Specific analysis model elements, and ๏ต c. The availability of architectural patterns.
- 14. iii. Interface design elements: ๏ตequivalent to a set of detailed drawings for the doors, windows, and external utilities of a house. ๏ตThere are 3 important elements of interface design: ๏ต a. The user interface(UI); ๏ต b. External interfaces to other systems, devices, networks, or other produces or consumers of information; and ๏ต c. Internal interfaces between various design components. iv. Component- level design elements: ๏ตIt is equivalent to a set of detailed drawings. ๏ตThe component-level design for software fully describes the internal detail of each software component. v. Deployment-level design elements: ๏ตIt indicates how software functionality and subsystems will be allocated within the physical computing environment that will support the software.
- 15. ARCHITECTURAL DESIGN SOFTWARE ARCHITECTURE: What Is Architecture? ๏ตArchitectural design represents the structure of data and program components that are required to build a computer-based system. ๏ตThe design of software architecture considers two levels of the design pyramid ๏ต - data design ๏ต - architectural design. Why Is Architecture Important? ๏ตRepresentations of software architecture are an enabler for communication between all parties (stakeholders) interested in the development of a computer-based system. ๏ตThe architecture highlights early design decisions that will have a profound impact on all software engineering work that follows and, as important, on the ultimate success of the system as an operational entity. ๏ตArchitecture โconstitutes a relatively small, intellectually graspable model of how the system is structured and how its components work togetherโ .
- 16. DATA DESIGN: ๏ตtranslates data objects as part of the analysis model into data structures at the software component level and, when necessary, a database architecture at the application level. 1.Data design at the Architectural Level: ๏ตThe challenge for a business has been to extract useful information from this data environment, particularly when the information desired is cross functional. 2. Data design at the Component Level: ๏ตfocuses on the representation of data structures that are directly accessed by one or more software components.
- 17. The following set of principles for data specification: 1. The systematic analysis principles applied to function and behavior should also be applied to data. 2. All data structures and the operations to be performed on each should be identified. 3. A data dictionary should be established and used to define both data and program design. 4. Low-level data design decisions should be deferred until late in the design process. 5. The representation of data structure should be known only to those modules that must make direct use of the data contained within the structure. 6. A library of useful data structures and the operations that may be applied to them should be developed. 7. A software design and programming language should support the specification and realization of abstract data types.
- 18. ARCHITECTURAL STYLES AND PATTERNS: ๏ตThe software that is built for computer-based systems also exhibits one of many architectural styles. ๏ตEach style describes a system category that encompasses (1) A set of components (2) A set of connectors (3) Constraints (4) Semantic models An architectural pattern, imposes a transformation the design of architecture. However, a pattern differs from a style in a number of fundamental ways: (1) The scope of a pattern is less broad, focusing on one aspect of the architecture rather than the architecture in its entirety. (2) A pattern imposes a rule on the architecture, describing how the software will handle some aspect of its functionality at the infrastructure level. (3) Architectural patterns tend to address specific behavioral issues within the context of the architectural
- 19. 1. A Brief Taxonomy of Styles and Patterns Data-centered architectures:
- 21. Call and return architectures: ๏ตMain program/subprogram architectures. ๏ตRemote procedure call architectures.
- 22. Object-oriented architectures: ๏ตThe components of a system encapsulate data and the operations that must be applied to manipulate the data. Layered architectures:
- 23. 2. Architectural Patterns: ๏ตThe architectural patterns for software define a specific approach for handling some behavioral characteristics of the system, ๏ต Concurrency ๏ต operating system process management pattern ๏ต task scheduler pattern ๏ต Persistence ๏ต a database management system pattern ๏ต an application level persistence pattern ๏ต Distribution ๏ตOrganization and Refinement: ๏ต it is important to establish a set of design criteria that can be used to assess an architectural design that is derived.
- 24. ARCHITECTURAL DESIGN: i. Representing the System in Context:
- 25. ii. Defining Archetypes: ๏ตAn archetype is a class or pattern that represents a core abstraction that is critical to the design of architecture for the target system.
- 26. iii. Refining the Architecture into Components: ๏ตAs the architecture is refined into components, the structure of the system begins to emerge.
- 27. iv. Describing Instantiations of the System:
- 28. A Conceptual Model of UML : ๏ตUML is a standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems. Object-Oriented Concepts ๏ตUML can be described as the successor of object-oriented (OO) analysis and design. ๏ตFollowing are some fundamental concepts of the object-oriented world, ๏ตObjects โ Objects represent an entity and the basic building block. ๏ตClass โ Class is the blue print of an object. ๏ตAbstraction โ Abstraction represents the behavior of an real world entity. ๏ตEncapsulation โ Encapsulation is the mechanism of binding the data together and hiding them from the outside world. ๏ตInheritance โ Inheritance is the mechanism of making new classes from existing ones. ๏ตPolymorphism โ It defines the mechanism to exists in different forms.
- 29. OO Analysis and Design: ๏ตOO can be defined as an investigation and to be more specific, it is the investigation of objects. Design means collaboration of identified objects. ๏ตThe purpose of OO analysis and design can described as โ ๏ต Identifying the objects of a system. ๏ต Identifying their relationships. ๏ต Making a design, which can be converted to executables using OO languages. ๏ตThere are three basic steps where the OO concepts are applied and implemented. The steps can be defined as, OO Analysis โ OO Design โ OO implementation using OO languages
- 30. Basic Structural Modeling: ๏ตStructural modeling captures the static features of a system. They consist of the following โ ๏ต Classes diagrams ๏ต Objects diagrams ๏ต Deployment diagrams ๏ต Package diagrams ๏ต Composite structure diagram ๏ต Component diagram ๏ตStructural model represents the framework for the system and this framework is the place where all other components exist.
- 31. Class Diagram: ๏ตClass diagram is a static diagram that shows a collection of classes, interfaces, associations, collaborations, and constraints. Purpose of Class Diagrams ๏ต Analysis and design of the static view of an application. ๏ต Describe responsibilities of a system. ๏ต Base for component and deployment diagrams.
- 32. The Sequence Diagram: ๏ตThe sequence diagram has four objects (Customer, Order, SpecialOrder and NormalOrder).
- 34. Use Case Diagram: ๏ตIt is used to represent the dynamic behavior of a system. ๏ตIt encapsulates the system's functionality by incorporating use cases, actors, and their relationships. Purpose of Use Case Diagrams 1. It gathers the system's needs. 2. It depicts the external view of the system. 3. It recognizes the internal as well as external factors that influence the system. 4. It represents the interaction between the actors. Some rules that must be followed while drawing a use case diagram: 1. A pertinent and meaningful name should be assigned to the actor or a use case of a system. 2. The communication of an actor with a use case must be defined in an understandable way. 3. Specified notations to be used as and when required. 4. The most significant interactions should be represented among the multiple no of interactions between the use case and actors.
- 37. Component diagram: ๏ตused to model the physical aspects of a system. ๏ตPhysical aspects are the elements such as executables, libraries, files, documents, etc. which reside in a node. Purpose of Component Diagrams ๏ต Visualize the components of a system. ๏ต Construct executables by using forward and reverse engineering. ๏ต Describe the organization and relationships of the components.