Software Design. Software Design. Software design is the process that adds implementation details to the requirements.

Full text

(1)Software Design. Software Design Software design is the process that adds implementation details to the requirements. • It produces a design specification that can be mapped onto a program. • It may take several iterations to produce a “good” design specification. • It may also produce several design specifications that correspond to different views of the same software product.. 1.

(2) Requirements vs. Design ◊ Requirements describe “WHAT” the system is supposed to do; design describes “HOW” the requirements will be implemented • Add implementation oriented details without changing the functionality in a requirement. ◊ Designing too early leads to narrow “requirements” and biases the project toward a particular implementation.. Requirements vs. Design – an informal example In an “automated ticketing system in a parking lot” • Issue Ticket Requirement: “When a vehicle enters, print a ticket with date and time; record date and time; issue the ticket to the vehicle.”. • Design: “ticket  issueTicket()” ticket  createTicket(); ticket.date  getCurrentDate(); ticket.time  getCurrentTime(); updateTickets (ticket); (Format of “ticket”, “date” and “time” must have been defined already.). 2.

(3) Requirements vs. Design – another informal example In the personal organizer example, • Select Contact List Requirement • Design: “selectContactList()” if ((fp = open (phFile)) != null) { i = 1; while (i < MAX_PHONE_ENTRIES && !end_of_file (fp)) { phEntries[i]  read (fp); i++; } } else throw FileOpenErrorException;. Design vs. Implementation Design adds implementation-oriented details but should not be the final implementation. • See the design example in the previous slide. • The choice of “File” and its format, and the choice of “read” procedure are left to the implementer.. 3.

(4) Design Principles by Alan Davis ◊ A design process should not have tunnel vision. – It should consider all possible solutions and make use of all available resources.. ◊ A design specification should have mechanisms to trace back to requirements. – It should be easy to identify mistakes later on and is also easy to add more features to the software product.. ◊ A design process should not reinvent the wheel. – It should try to make use of previous design patterns, resources and experiences as much as possible.. ◊ A design specification should be structured to accommodate changes. – It should be easier if it follows some standards such as IEEE, ANSI, ISO, etc.. Design Evaluation ◊ A software design must include all explicit and implicit requirements given in the requirements document. – Nothing should be left out from the requirements document.. ◊ A design specification must be readable, understandable by the implementation team, and should be verifiable for consistency and correctness. ◊ A design specification must be implementable. – Mapping to a program should be straightforward.. ◊ A design must support modular structures.. 4.

(5) Software Architectures: Data-centered Architecture • A data store (database or data warehouse) is modeled as the centerpiece of the architecture. • All modules, subsystems, procedures etc. are described in terms of their operational characteristics on the data store (add, delete, modify, etc.). • Useful for data-oriented applications Example: reservation systems. • No particular commonly used design notation. 5.

(6) Software Architectures: Data-flow Architecture • A set of software components called filters connected by a set of connectors called pipes. • Data flows through the pipes and processed (or filtered) by the filters. • A data transformation may occur at each filter. • Common architecture for legacy systems. • Commonly used design notation ◊ Data flow diagrams. 6.

(7) Software Architectures: Control Architecture • Programming modules (or subsystems) are divided into sub-modules (or modules). • Relationships among sub-modules (or modules) indicate method calls and return mechanisms. • Execution thread can be easily identified. • Concurrency and multiple threads of control can be explored. • Commonly used design notation ◊ Structure charts ◊ Jackson’s System Development (JSD) method. 7.

(8) Software Architectures: Layered Architecture • Applicable to complex systems that are divided into several layers. ◊ Example: OSI network architecture (7 layers) ◊ Example: Operating system. • Outer layers are more abstract than the inner layer(s). • Each layer can be modeled using any of the other architectural styles. • No particular commonly-used design notation. 8.

(9) Software Architectures: Object-oriented Architecture • OOD - Object-oriented Design: 1 2 3 4 . Identify the objects (nouns) from the requirements. Group objects of similar type into classes. Create Class Diagrams (including methods and scope) Create class specifications (class invariants, method preconditions and method postconditions). • OOD is well-suited to many contemporary projects. ◊ OOD works well with GUIs. ◊ OOD supported by popular programming languages.. • UML notations, especially class diagrams are commonly used.. Class Diagram Color. class name. - redness : int . - blueness : int . - greenness : int . - opaqueness : int. attributes. «constructor». + Color(int r, int g, int b) . + Color(float r, float g, float b, float a). «query». + int getRed() . + Color darker(). + Color brighter(). methods. . . .. 9.

(10) Class Specification java.awt.Color Class Specifications. Invariant (for every Color object, c). 0 ≤ redness ≤ 255 and 0 ≤ greenness ≤ 255. and 0 ≤ blueness ≤ 255 and 0 ≤ opaqueness ≤ 255. Constructor Methods. public Color(int r, int g, int b) . pre: 0 ≤ r ≤ 255 and 0 ≤ g ≤ 255 and 0 ≤ b ≤ 255. (throws IllegalArgumentException). post: redness == r and greenness == g and blueness == b and opaqueness == 255. public Color(float r, float g, float b, float a) . pre: 0.0 ≤ r ≤ 1.0 and 0.0 ≤ g ≤ 1.0 and 0.0 ≤ b ≤ 1. 0 and 0.0 ≤ a ≤ 1.0. (throws IllegalArgumentException). post: redness == r*255 and greenness == g*255 . and blueness == b*255 and opaqueness == a*255. Class Specification (cont’d) java.awt.Color Class Specifications. (continued). Query Methods. public int getRed() . post: result == redness. public Color darker() . post: result.redness == redness * 0.7 . and result. greenness == greenness * 0.7 . and result. blueness == blueness * 0.7 . and result. opaqueness == 255. public Color brighter() . post: (redness / 0.7) > 255 implies result.redness == 255. and (redness / 0.7) ≤ 255 implies result.redness == redness / 0.7 . and (greenness / 0.7) > 255 implies result. greenness == 255. and (greenness / 0.7) ≤ 255 implies result. greenness == greenness / 0.7 . and (blueness / 0.7) > 25 5 implies result. blueness == 255. and (blueness / 0.7) ≤ 255 implies result. blueness == blueness / 0.7 . and result. opaqueness == 255. . . .. Notation: result refers to the return value.. 10.

(11) Interface design ◊ Describes communication links between elements of the system, and between the system and the environment (external to the system); the latter is called “user-interface”. ◊ Flow of data and control between each pair of elements, as well as between the system and the external environment, are identified. ◊ Commonly used design notations: • Data flow diagrams • Use case diagrams • State transition diagrams. Component-level design ◊ Component-level design provides a more detailed description of each element of the system such as procedures, algorithms, packages, modules, subsystems and the system as a whole. ◊ Each data element is mapped to data type(s) in the implementation programming language. ◊ This is the last level of refinement of data design and architectural design. ◊ Commonly used design notations: • Flow charts • Class specifications • Design languages (e.g., Ada). 11.

(12)

No results found