1. Trang chủ
  2. » Tất cả

Ch7 detail design

37 0 0

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 37
Dung lượng 1,49 MB

Nội dung

1/20/2015 SOFTWARE ENGINEERING Chapter – Detail Design Jul 2013 Chapter Software Detail Design Topics covered • Object-oriented design using the UML • Design patterns • Open source development • More 1/20/2015 Jul 2013 Chapter Software Detail Design Design and implementation • Software design and implementation is the stage in the software engineering process at which an executable software system is developed • Software design and implementation activities are invariably inter-leaved • Software design is a creative activity in which you identify software components and their relationships, based on a customer’s requirements • Implementation is the process of realizing the design as a program Jul 2013 Chapter Software Detail Design Build or buy • In a wide range of domains, it is now possible to buy off- the-shelf systems (COTS) that can be adapted and tailored to the users’ requirements • For example, if you want to implement a medical records system, you can buy a package that is already used in hospitals It can be cheaper and faster to use this approach rather than developing a system in a conventional programming language • When you develop an application in this way, the design process becomes concerned with how to use the configuration features of that system to deliver the system requirements 1/20/2015 Jul 2013 Chapter Software Detail Design An object-oriented design process • Structured object-oriented design processes involve developing a number of different system models • They require a lot of effort for development and maintenance of these models and, for small systems, this may not be cost-effective • However, for large systems developed by different groups design models are an important communication mechanism Jul 2013 Chapter Software Detail Design Process stages • There are a variety of different object-oriented design processes that depend on the organization using the process • Common activities in these processes include: • Define the context and modes of use of the system; • Design the system architecture; • Identify the principal system objects; • Develop design models; • Specify object interfaces • Process illustrated here using a design for a wilderness weather station 1/20/2015 Jul 2013 Chapter Software Detail Design System context and interactions • Understanding the relationships between the software that is being designed and its external environment is essential for deciding how to provide the required system functionality and how to structure the system to communicate with its environment • Understanding of the context also lets you establish the boundaries of the system Setting the system boundaries helps you decide what features are implemented in the system being designed and what features are in other associated systems Jul 2013 Chapter Software Detail Design Context and interaction models • A system context model is a structural model that demonstrates the other systems in the environment of the system being developed • An interaction model is a dynamic model that shows how the system interacts with its environment as it is used 1/20/2015 Jul 2013 Chapter Software Detail Design System context for the weather station Jul 2013 Chapter Software Detail Design 10 Weather station use cases 1/20/2015 Jul 2013 Chapter Software Detail Design 11 Use case description—Report weather System Weather station Use case Report weather Actors Weather information system, Weather station Description The weather station sends a summary of the weather data that has been collected from the instruments in the collection period to the weather information system The data sent are the maximum, minimum, and average ground and air temperatures; the maximum, minimum, and average air pressures; the maximum, minimum, and average wind speeds; the total rainfall; and the wind direction as sampled at fiveminute intervals Stimulus The weather information system establishes a satellite communication link with the weather station and requests transmission of the data Response The summarized data is sent to the weather information system Comments Weather stations are usually asked to report once per hour but this frequency may differ from one station to another and may be modified in the future Jul 2013 Chapter Software Detail Design 12 Architectural design • Once interactions between the system and its environment have been understood, you use this information for designing the system architecture • You identify the major components that make up the system and their interactions, and then may organize the components using an architectural pattern such as a layered or client-server model • The weather station is composed of independent subsystems that communicate by broadcasting messages on a common infrastructure 1/20/2015 Jul 2013 Chapter Software Detail Design 13 High-level architecture of the weather station Jul 2013 Chapter Software Detail Design 14 Architecture of data collection system 1/20/2015 Jul 2013 Chapter Software Detail Design 15 Object class identification • Identifying object classes is toften a difficult part of object oriented design • There is no 'magic formula' for object identification It relies on the skill, experience and domain knowledge of system designers • Object identification is an iterative process You are unlikely to get it right first time Jul 2013 Chapter Software Detail Design 16 Approaches to identification • Use a grammatical approach based on a natural language description of the system (used in Hood OOD method) • Base the identification on tangible things in the application domain • Use a behavioural approach and identify objects based on what participates in what behaviour • Use a scenario-based analysis The objects, attributes and methods in each scenario are identified 1/20/2015 Jul 2013 Chapter Software Detail Design 17 Weather station description • A weather station is a package of software controlled instruments which collects data, performs some data processing and transmits this data for further processing The instruments include air and ground thermometers, an anemometer, a wind vane, a barometer and a rain gauge Data is collected periodically • When a command is issued to transmit the weather data, the weather station processes and summarises the collected data The summarised data is transmitted to the mapping computer when a request is received Jul 2013 Chapter Software Detail Design 18 Weather station object classes • Object class identification in the weather station system may be based on the tangible hardware and data in the system: • Ground thermometer, Anemometer, Barometer • Application domain objects that are ‘hardware’ objects related to the instruments in the system • Weather station • The basic interface of the weather station to its environment It therefore reflects the interactions identified in the use-case model • Weather data • Encapsulates the summarized data from the instruments 1/20/2015 Jul 2013 Chapter Software Detail Design 19 Weather station object classes Jul 2013 Chapter Software Detail Design 20 Design models • Design models show the objects and object classes and relationships between these entities • Static models describe the static structure of the system in terms of object classes and relationships • Dynamic models describe the dynamic interactions between objects 10 1/20/2015 Jul 2013 Chapter Software Detail Design 45 Component/system deployment factors • If a component is designed for a specific hardware architecture, or relies on some other software system, it must obviously be deployed on a platform that provides the required hardware and software support • High availability systems may require components to be deployed on more than one platform This means that, in the event of platform failure, an alternative implementation of the component is available • If there is a high level of communications traffic between components, it usually makes sense to deploy them on the same platform or on platforms that are physically close to one other This reduces the delay between the time a message is sent by one component and received by another Jul 2013 Chapter Software architecture design 46 Midterm Exam Revisited (Again) Xét hệ thống phần mềm hỗ trợ hoạt động chuỗi cửa hàng bán lẻ thuộc tập đoàn Z chuyên cung cấp mặt hàng phục vụ khách nhà ga xe lửa nhật báo, kẹo bánh, snack, ca phê pha sẵn, khăn giấy Mỗi cửa hàng miêu tả qua tên, địa ký hiệu cho biết quy mơ (z, zz zzz tương ứng với cửa hàng loại nhỏ, vừa lớn) Mỗi cửa hàng điều hành cửa hàng trưởng, vài nhân viên quầy tính tiền nhân viên hậu cần Chính sách giá chế độ khuyến tất chuỗi bán lẻ thuộc Z thực đồng nước (ví dụ mì gói ly khuyến nửa giá tuần, giá bán snack giống toàn quốc) Tuy nhiên cửa hàng cần quản lý nhập xuất số lượng hàng riêng (ví dụ cà phê khuyến hết hàng cửa hàng đó) Hệ thống phần mềm giúp nhân viên quầy thu tiền quét mã vạch in hóa đơn cho khách Trong hóa đơn có ghi ngày giao dịch, tên nhân viên thu tiền địa cửa hàng tất nhiên danh sách mặt hàng mua với tổng số tiền Phần mềm giúp trưởng cửa hàng tạo báo cáo thống kê theo ngày, tuần, tháng hay quý kiểm tra mặt hàng bán hết Phần mềm có chức xác thực thẻ (đối với nhân viên quầy tính tiền) thông qua mật (trưởng cửa hàng) 23 1/20/2015 Jul 2013 Chapter Software Detail Design 47 Z chain - Object/Class Identification • Refers to Slide #16 • Count how many nouns you get from the requirements • Could they be all objects/classes? • Some of them really are objects Others could simply be the attributes of them • Populate your Classes or Objects • Identify relationship between your classes • Make a class diagram Jul 2013 Chapter Software Detail Design 48 Z chain - Interface Design • Define a few interfaces for your classes 24 1/20/2015 Jul 2013 Chapter Software Detail Design 49 Open source development • Open source development is an approach to software development in which the source code of a software system is published and volunteers are invited to participate in the development process • Its roots are in the Free Software Foundation (www.fsf.org), which advocates that source code should not be proprietary but rather should always be available for users to examine and modify as they wish • Open source software extended this idea by using the Internet to recruit a much larger population of volunteer developers Many of them are also users of the code Jul 2013 Chapter Software Detail Design 50 Open source systems • The best-known open source product is, of course, the Linux operating system which is widely used as a server system and, increasingly, as a desktop environment • Other important open source products are Java, the Apache web server and the mySQL database management system 25 1/20/2015 Jul 2013 Chapter Software Detail Design 51 Open source issues • Should the product that is being developed make use of open source components? • Should an open source approach be used for the software’s development? Jul 2013 Chapter Software Detail Design 52 Open source business • More and more product companies are using an open source approach to development • Their business model is not reliant on selling a software product but on selling support for that product • They believe that involving the open source community will allow software to be developed more cheaply, more quickly and will create a community of users for the software 26 1/20/2015 Jul 2013 Chapter Software Detail Design 53 Open source licensing • Afundamental principle of open-source development is that source code should be freely available, this does not mean that anyone can as they wish with that code • Legally, the developer of the code (either a company or an individual) still owns the code They can place restrictions on how it is used by including legally binding conditions in an open source software license • Some open source developers believe that if an open source component is used to develop a new system, then that system should also be open source • Others are willing to allow their code to be used without this restriction The developed systems may be proprietary and sold as closed source systems Jul 2013 Chapter Software Detail Design 54 License models • The GNU General Public License (GPL) This is a so- called ‘reciprocal’ license that means that if you use open source software that is licensed under the GPL license, then you must make that software open source • The GNU Lesser General Public License (LGPL) is a variant of the GPL license where you can write components that link to open source code without having to publish the source of these components • The Berkley Standard Distribution (BSD) License This is a non-reciprocal license, which means you are not obliged to re-publish any changes or modifications made to open source code You can include the code in proprietary systems that are sold 27 1/20/2015 Jul 2013 Chapter Software Detail Design 55 License management • Establish a system for maintaining information about • • • • • open-source components that are downloaded and used Be aware of the different types of licenses and understand how a component is licensed before it is used Be aware of evolution pathways for components Educate people about open source Have auditing systems in place Participate in the open source community Jul 2013 Chapter Software Detail Design 56 Summary • Software design and implementation are inter-leaved activities The level of detail in the design depends on the type of system and whether you are using a plan-driven or agile approach • The process of object-oriented design includes activities to design the system architecture, identify objects in the system, describe the design using different object models and document the component interfaces • A range of different models may be produced during an object-oriented design process These include static models (class models, generalization models, association models) and dynamic models (sequence models, state machine models) • Component interfaces must be defined precisely so that 28 1/20/2015 Jul 2013 Chapter Software Detail Design 57 Summary (cont.) • When developing software, you should always consider the possibility of reusing existing software, either as components, services or complete systems • Configuration management is the process of managing changes to an evolving software system It is essential when a team of people are cooperating to develop software • Most software development is host-target development You use an IDE on a host machine to develop the software, which is transferred to a target machine for execution • Open source development involves making the source code of a system publicly available This means that many people can propose changes and improvements to Jul 2013 Chapter Software Detail Design 58 More ? • UI (User Interface) design • Graphic (GUI) ? • Package/Class design (?) • Database design (?) 29 1/20/2015 Jul 2013 Chapter Software Detail Design 59 Specify A Class • Gather the attributes listed in the SRS • if the SRS is organized by class • Add additional attributes required for the design • Name a method corresponding to each of the requirements for this class • easy if the SRS is organized by class • Name additional methods required for the design • Show the attributes & methods on the object model • State class invariants Jul 2013 Chapter Software Detail Design 60 Specify a Function • Note the section(s) of the SRS or SDD which this • • • • function (method) satisfies State what expressions the function must leave invariant State the method’s pre-conditions (what it assumes) State the method’s post-conditions (its effects) Provide pseudocode and/or a flowchart to specify the algorithm to be used • unless very straightforward 30 1/20/2015 Jul 2013 Chapter Software Detail Design 61 Classes at Detailed Design Canister +: visible from without + numCanisters: int - numWafers: int - size: float Attribute: type + display() - getNumSlotsOpen() + setStatus() Operations Responsibilities: describes each canister undergoing fabrication Jul 2013 Class name Chapter Software Detail Design Place for comments 62 Class/Function Invariants, Pre- and Postconditions • Class invariant: • Remain true throughout a designated computation • Ex: Account class: liquidAssetsI

Ngày đăng: 02/04/2023, 12:15