Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.


Software Design

Part of the lecture "Software Engineering" for second year students in Computer Science at Durham University. This lecture is based heavily on the book "Software Engineering", ninth edition, by Ian Sommerville.

Pedro Gonnet

on 11 September 2013

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Software Design

Software Design Architectural design Architectural design is the process of producing a model that defines the structure of a system and the relationship between its components. Object-oriented design Application architecture Architectural patterns Object identification Design models Interface design The specification of the interfaces between the components of a system is an important part of any design. Make communication, system analysis, and large-scale reuse more efficient by facilitating discussion and documentation of the design. Architectural design is a creative process, and thus there is no straight-forward approach. Similar systems have similar architectures, and experience with one can help with another. Definition Application architectures describe the structure and organization of particular types of software systems. What they are used for Transaction processing systems Transaction processing systems are designed to process user requests for information from a database, or requests to update a database. Information systems Information systems are systems that interact with a shared database in a more elaborate way than transaction processing systems do. Language processing systems Language processing systems process, e.g. translate or execute, statements written in a natural or artificial language. Definition Architectural patterns are a way of presenting, sharing and reusing knowledge about software systems. Model-View-Controller pattern The Model-View-Controller (MVC) pattern separates the representation of system data (Model) from its presentation (View) and the way the user interacts with it (Controller). Layered architecture In a layered architecture, the system functionality is organized into separate layers, and each layer relies only on the functionality of the layer directly below it. Client-server architecture The client-server architecture is commonly used for the run-time organization of distributed systems in which the functionality of the system is organized into services, each delivered from a separate server. Pipe and filter architecture The pipe and filter architecture is used to model systems in which functional transformations process their inputs and produce outputs. either sequentially or in parallel. Relation to application architectures Application architectures specify what a program does, whereas the architectural patterns specifies how it is done specifically. Although every system is different, common architectural structure can be reused for similar systems. Common architectural structures can be useful in a number of ways: As a starting point: If unfamiliar with the type of system to be designed, the initial design can be based on a generic architecture. As a design checklist: Is the proposed design consistent with the generic architecture? As a form of reuse: Identify similar components between architectures that may be reused from other projects.. As a vocabulary: Common concepts make discussion easier. As an organizational tool: Identify major parts that can be developed concurrently. Application architectures encapsulate the principal characteristics of a class of systems, e.g. transaction processing systems, information systems, or language processing systems. These are rough descriptions of what a system does and how it is organized, i.e. which distinct parts do what. A transaction is a sequence of operations that is treated as a single, or atomic, unit which need to succeed before the transaction is made permanent. Most web-based services are transaction-based system in which a server is polled with an HTTP request and returns some form of data. This is also true of how a bank handles transactions, or an airline manages bookings. The main purpose of such systems is to make data or content accessible, e.g. search engines of any type, or online news sites. Data is usually not returned in its raw form, but may be additionally processed, e.g. sorted, filtered, or aggregated from several sources. Both the query and result data can be of various different types, e.g. text, images, or geographical information. Such systems are commonly used for compiling programming languages into machine-executable code, or parsing HTML for displaying web pages. Despite the different intricacies of each type of input language, the structure of such a system, i.e. a parser, usually relies on the same components. Summary Similar applications have similar architectures. In many cases, these architectures can be reused as a starting point, checklist, source of components, and communication and organization aids. These similarities may not always be entirely obvious. The concept of design patterns was introduced by the so-called "Gang of four", Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides in their 1995 book, and subsequently extended by several other authors. Each design pattern represents a stylized, abstract description of good practice, which has been tried and tested in different systems. Architectural design patterns are one of several families, e.g. creational patterns, structural patterns, and behavioral patterns, of which we will see more later on. Repository architecture As opposed to the MVC and layer patterns, which show how a system is organized, the repository architecture shows how different interacting components can share data. Summary Architectural patterns are a useful abstraction for describing how certain processes will be implemented. The Model component manages the data and its associated operations. The View component receives data from the model for display. The Controller component manages user interaction with the data. Multiple views and controllers can be used for the same data in different contexts. The notions of separation and independence are fundamental to architectural design, as they allow changes to be localized. As long as the interfaces are preserved, the individual layers can be modified or replaced without changing the entire system. This is important, e.g. for hardware-independent architectures. Architectural views It is usually impossible to represent all the relevant information in a single architectural model, which is why we distinguish between 4+1 fundamental architectural views: Logical view: Shows key system abstractions as objects or object classes. Physical view: Shows how the software and hardware are distributed. Development view: Shows how the software is decomposed, i.e. the breakdown of the software into individual components, for development. Process view: Shows how, at run time, the system is composed of interacting processes. Most information systems with large amounts of data are organized around a shared database or repository. Instead of interacting directly with each other, each part of the system interacts only via the repository. Components can thus be made completely independent of each other, as long as they adhere to the same data formats. The clients and servers need not be distributed physically, but may all reside on the same machine. Interactions usually follow simple request-reply protocols. The capacity of such systems can be extended by replicating servers to handle clients concurrently. Often used for simple processes or automatic data processing systems, e.g. embedded systems, or billing systems. The name comes from the UNIX command line, where the output of one program can be "piped" directly as the input to another program. The information system architecture described earlier could be implemented both using a MVC pattern or a layered architecture pattern. Different patterns provide different views of the systems, e.g. how its data is structured or how it reacts to inputs. Whereas Application architectures describe what a system does, architectural patterns describe how this is done. Design Document The design process The object-oriented design process involves designing object classes and the relationships between these classes. Object oriented design vs. programming Object-oriented programming is a programming paradigm, or concept, which attempts to unify data and methods on said data, into objects. Design patterns This is a creative process, and there is therefore no clear-cut, sequential recipe that can be followed. The following only describes the steps that need to be taken, but these are usually taken concurrently or iteratively. Iterative refinement is commonly used, i.e. start with a high-level abstraction of the main objects in the system and successively break them down into their respective parts to add detail. Knowledge and intuition from Computer Science and programming will help you through the process. As such, object-oriented design is not restricted to object-oriented programming languages such as Java or C++. For example, the Linux GNOME Desktop is built using GTK+, an object-oriented library written in plain C. Fully object-oriented languages are required in systems where features such as dynamic polymorphism are used. Object identification By the time you reach this stage, you should have some idea about the essential objects in the system you are designing. Methodologies Several methodologies for the systematic identification of object classes have been described: Example: Initial model From the user requirements of a software system to manage a school: Example: Refinement Using more detailed user and system requirements, the initial set of objects can be refined and/or extended: Example: Reuse Often, when objects have been broken-down to their individual components, re-usable object types may emerge: During the design phase, you will re-evaluate and refine these ideas. The system models developed in the requirements phase, e.g. the use cases, offer a good starting point for identifying the main system components. Objects can be identified hierarchically, e.g. higher-level system objects can themselves be decomposed into any number of smaller, interacting objects. Grammatical analysis: Requirements specified in natural language, e.g. using nouns, adjectives and verbs, can be converted into objects, attributes, and operations, respectively. Tangible objects: Use knowledge of the application domain, e.g. the concepts or "things" as they are described therein. Scenario-based analysis: In each scenario in the requirements, each part can be considered a separate object. Since none of these methods alone is sufficient to identify all objects at all levels of detail, usually several methods will be used concurrently. The system provides a tool to manage all school functions, i.e. facilities, classes and people. From this description, we can extract an initial set of objects: Facilities: The physical infrastructure of the school, Classes: An abstract domain-specific unit, People: System actors involved with the school. Main concepts During the requirements engineering phase, we already encountered the use of UML to describe system models. Structural models Structural models describe the static structure of a system using object classes and their relationships. Subsystem models Subsystem models are used to represent high-level logical groupings of objects into coherent subsystems. Sequence models Sequence models show the sequence of interactions between objects. State machine models If any of the objects in the system have some notion of state, state machine models can be used to describe how they go from one state to the other in response to inputs and/or events. Such models exist at different levels of details, or levels of abstraction, for different intended audiences, e.g. end users or developers. Design models are similar to system models, yet differ in that they describe how something is done, as opposed to what is done. These models show how the objects defined in the object identification phase interact with, or relate to, each other. The most important features are: Generalizations, i.e. inheritance, for similar object types, Encapsulation, i.e. which object classes contain references to other object classes. Aggregation, i.e. which object classes are compositions of other classes. Usually modeled using UML class diagrams. These models are more organizational in nature, i.e. they show which parts of the system can be modeled or designed as a single entity. In our example system, all data pertaining to facilities, i.e. buildings and rooms, is grouped into a single package. As opposed to the structural and subsystem models, the sequence model is a dynamic model, e.g. it shows how the objects react to inputs or changes of state. As within the system models, UML sequence diagrams are used, yet now with specific object classes and method names to describe each interaction in terms of how it is implemented. Such models should be produced for each significant interaction within the system, e.g. for each use case. This is also a dynamic model, but as opposed to sequence models, it describes only what happens within a given object. Since most of the objects in a system are usually relatively simple, not all of them will require a state diagram. Useful for checking for inconsistencies, e.g. what effect a method or input will have for any given state. Once interfaces have been specified, different parts of the system can be developed concurrently. The interface definition should not include details of the data representation, e.g. accessing an object's fields should be implemented via "getters" and "setters", such that changing the data model does not affect the interface. Interfaces are usually considered to be calling conventions, i.e. function names, parameters, and return values, although some languages provide explicit interface definitions. Classification Object-oriented design patterns are usually grouped into three categories: Adaptor pattern Also referred to as wrapper or translator pattern, the adaptor pattern is used to translate the interface of an object, e.g. into a more convenient or standardized interface. Facade pattern The facade pattern describes an object, referred to as the facade object, which provides a unique and/or simplified interface to a larger, more complex subsystem. Decorator pattern The decorator pattern describes a mechanism for adding functionality to an existing object at runtime. Factory method pattern The factory method pattern is a creational pattern that specifies factory objects whose purpose is to generate objects of a given class. Abstract factories pattern The abstract factory pattern is similar to the factory pattern, but differs in that it provides a class whose sole purpose is to produce a set of objects of the correct type. Singleton pattern The role of the singleton pattern is to ensure that only one instance of a given object class exists. Iterator pattern The iterator is a behavioural pattern which provides a mechanism, similar to a for-loop, for iterating over a collection of objects. Observer pattern The observer pattern represents a method to receive notifications from an object, e.g. on a change of state or on activity. Strategy pattern The strategy pattern implements a form of polymorphism for functions, i.e. an object class is used to encapsulate a single functionality as a method which is implemented differently by each of its subclasses. Template pattern The template pattern is a way of representing entire algorithms with customizable and/or replacable parts. Creational patterns: Describe how instances of objects are created to satisfy specific user requests. Structural patterns: Describe different models for the relationship between object classes. Behavioural patterns: Describe how objects communicate between each other or react to inputs. As with architectural design patterns, object oriented design patterns represent experience and best practice in a general and reusable way. This is often used when incorporating objects or functionality from standard libraries that use an interface different to the ones used in the system. Adaptor classes are understood to only pass on, and if necessary translate, the input and output, i.e. no additional functionality is added. This pattern hides the complexity of a larger subsystem behind a simpler and potentially reduced interface. Any changes in the design or interfaces within the subsystem only has to be adapted in the facade object. Can also be used to aggregate the functionality of several different subsystems. Instead of defining a new object class, the object is wrapped in another object with the same interface, which provides additional functions. Multiple decorators can be added on top of each other, thus accumulating extra functionality. This is how I/O-streams are created/handled in Java! This can be of use when working with an interface that provides, for example, an abstract tree which can be either a binary tree or an AVL tree. An abstract factory could then provide the correct type of node for each data structure. This can be used e.g. for cross-platform GUIs, in which abstract factories are used to create the corresponding widgets for each platform. The +1 view consists of scenarios which may embody the other views. Ideally, a constructor or factory for such a singleton object should always return the same instance. This, however, is non-trivial for many object oriented languages, e.g. in Java, and requires some extra machinery. Since the constructor is private, it can not be called from outside the object, and thus Singleton.getInstance() has to be used to retrieve the single instance. Iterators usually have only two functions, "hasNext()" which determines if there are still objects over which to iterate, and "next()" which provides a pointer to the next object. Iterators are usually generated using factories, i.e. the object class storing the data, e.g. an array, linked list, or tree, provides a method which returns a concrete iterator specific to that class. Observable objects must provide methods to register, unregister, and notify a set of observer objects. The observer object itself provides a function which is called whenever there is a notification. In the MVC architectural pattern, the View object can be implemented as an observer that reacts to notifications from the Model. It is up to the calling class to pick the correct strategy object, unless it is combined with the factory pattern to automatically produce the correct strategy for a given problem. In programming languages that support function pointers, the encapsulation in an object class is not required. As with the strategy pattern, an object class is used only to encapsulate specific behaviours, which is not necessarily required for languages that support function pointers. The individual steps can be declared as "virtual" or have default implementations. Inversion of control principle, e.g. the "don't call us, we'll call you", or Hollywood principle. About this lecture Software design process For the next seven lectures, I will be talking about software design. As you may have already noticed, the slides for this lecture are somewhat unconventional: they are a "Prezi" presentation. The slides are made available online in this same format, where they can be viewed and navigated as in the lecture. The slides can also be exported as a PDF and printed, but this is not recommended as they are not yet in their final state. As this is the first time I am lecturing in Software Engineering, please do let me know if you feel something could be done better or differently. I will try to remember to make a break in the middle of each lecture and talk about something completely different for 5 minutes. Whereas the requirements phase was concerned with what a software system does, the design phase deals with how it will do so. The goal of the design phase is to produce a sufficiently complete description of the system such that it can be implemented. This is a creative process, and as such there is no fixed methodology with which to proceed. Although distinct tasks exist, they are strongly correlated, and the order in which they are processed is by no means fixed. The following slides rely heavily on UML and object oriented programming techniques, whereby the former is not used rigorously, and the latter does not imply the use of an object oriented programming language. Purpose The software design document shows how the software system will be structured to satisfy the requirements identified in the software requirements specification. Terminology The IEEE 1016-1998 "Recommended Practice for Software Design Descriptions" uses the following terminology when referring to software designs: Design entities A design entity is an element of a design that is structurally and functionally distinct from other elements and that is separately named and referenced. Entity attributes A design entity attribute is a named characteristic or property of a design entity, i.e. it provides a statement of fact about the entity. Design views A design view is a subset of design entity attribute information, i.e. entities and their attributes. Document structure The IEEE 1016-1998 standard specifies six main document sections: In a complete software design document, each requirement must be traceable to one or more design entities. In essence, the design document becomes a detailed blueprint for the implementation activity. It is a translation of requirements into a description of the software structure, software components, interfaces, and data necessary for the implementation phase. Design entity: An element (component) of a design that is structurally and functionally distinct from other elements and that is separately named and referenced. Entity attribute: A named characteristic or property of a design entity. It provides a statement of fact about the entity. Design view: A subset of design entity attribute information that is specifically suited to the needs of a software project activity. Although entities are different in nature, they possess common characteristics, e.g. name, purpose, and function, and common relationships among entities, e.g. interfaces or shared data. Entities can exist as a system, subsystems, data stores, modules, programs, and processes. Design entities result from a decomposition of the software system into separate components that can be considered, implemented, changed, and tested with minimal effect on other entities. Entity attributes can be thought of as questions about design entities where the answers to those questions are the values of the attributes. The IEEE 1016-1998 standard defines the following necessary attributes: Identity: A unique and descriptive name. Subordinates: The identification of all entities composing this entity. Function: A statement of what the entity does. In the case of a data entity, this attribute shall state the type of information stored or transmitted by the entity. Purpose: Provides the rationale for the creation of the entity, i.e. designates the specific functional and non-functional requirements that make this entity necessary. Type: Describes the nature of the entity, e.g. subprogram, module, procedure, process, or data store. Dependencies: A description of the relationships of this entity with other entities, including the nature of that relationship. Data: A description of data elements internal to the entity. Processing: A description of how the entity implements its functionality, e.g. the algorithms or the workflow used. Resources: A description of the elements used by the entity that are external to the design, e.g. physical devices or operating system services. Interface: A description of how other entities interact with this entity, e.g. what methods and how they are called. Different views provide details on different aspects of a software project. Decomposition description Scope: The decomposition description records the division of the software system into design entities, i.e. how the system has been structured and the purpose and function of each entity. Dependency description Detailed description Interface description Entity attributes: Descriptions for identification, type, purpose, function, and subordinates should be included for all entities in this design view. Use: The decomposition description can be used by designers and maintainers to identify the major design entities of the system for purposes such as determining which entity is responsible for performing specific functions and tracing requirements to design entities. Representation: UML class diagram, structured natural language. Scope: The dependency description specifies the relationships among entities, i.e. identifies the dependent entities, describes their coupling, and identifies the required resources. Entity attributes: Descriptions for identification, type, purpose, dependencies, and resources should be included for all entities in this design view. Use: The dependency description provides an overall picture of how the system works. Representation: Structure charts, data flow and transaction diagrams Scope: The entity interface description provides everything needed to know to correctly use the functions provided by an entity. Entity attributes: Descriptions for identification, function, and interfaces should be included for all entities in this design view. Use: The interface description serves as a binding contract among designers, programmers, customers, and testers, providing them with an agreement needed before proceeding with the detailed design of entities. Representation: Interface files, parameter tables. Scope: The detailed design description contains the internal details of each design entity. Entity attributes: Descriptions for identification, processing, and data should be included for all entities in this design view. Use: This description contains the details needed by programmers prior to implementation, e.g. detailed descriptions of algorithms or data layout that are not sufficiently well described by other views. Representation: Natural language, pseudo-code, tables. Introduction and references The software design document introduction should contain the following information: Decomposition description The decomposition description describes the division of the software system into design entities, e.g. how the system has been structured, and the purpose and function of each entity. Dependency description The dependency description specifies the relationships among entities, i.e. it identifies the dependent entities, describes their coupling, and identifies the required resources. Interface description The entity interface description provides everything designers, programmers, and testers need to know to correctly use the functions provided by an entity. Detailed design This final section should contain any additional information which was not provided in the previous sections. Introduction References Decomposition description Dependency description Interface description Detailed description Purpose: State the purpose of the design document, as well as the system objectives and goals. Scope: Overview of what the software will and will not do, e.g. what the main requirements are. Definitions: Technical terms, acronyms and abbreviations. Document information: Date published, authors, change history. Overview: Brief description of how the rest of the document will be structured. You should make different subsections for each type of entity, e.g. modules, concurrent processes, or data. The decomposition description is also used for specifying how specific functional requirements are mapped to the entities. Design entities can be grouped into major classes to assist in locating a particular type of information and to assist in reviewing the decomposition for completeness. Defines the strategies for interactions among design entities and provides the information needed to easily perceive how, why, where, and at what level system actions occur. Separate subsections for dependencies between modules, between processes, and between data, e.g. in a database. This description includes the details of both external and internal interfaces not provided in the software requirements specification. You should make a separate subsection for every entity that has an interface. Each entity interface description should contain everything another designer or programmer needs to know to develop software that interacts with that entity. Not every entity will necessarily require detailed design information! As these details do not fit in the common views and their representations, natural language is usually the most convenient way of describing them. Hidden detail often applies to data, e.g. consistencies in databases, specific number or data formats, or their representation when stored. Summary The software design document is a detailed description of a software design, along with the rationale used to develop it. The IEEE 1016-1998 standard specifies common entities, attributes a views which can be used to describe all aspects of the design. The IEEE 1016-1998 standard should be seen as a set of guidelines: Every project will have a different set of stakeholders with different levels of understanding, and you should tailor your document to your project and environment. The IEEE 1016-1998 standard has been revised, i.e. 1016-2009, but you should stick to the less strict original. Parallelism In recent years, computers have not been getting faster, but more parallel. Task-based parallelism Good parallelism is not something you do as an afterthought in a serial code, but a high-level design decision which affects how you will actually do your underlying computations. OpenMP-based parallelism Shared-memory parallel programming standard that uses compiler directives to automagically parallelize parts of the code. MPI-based parallelism The Message Passing Interface (MPI) is a incredibly popular standard library for distributed-memory parallelism. This means that if your software cannot exploit parallelism, it will never get any faster. Parallelism is measured in terms of efficiency and scaling. Parallelism is achieved by starting several copies of the same program on different machines, which then communicate via "messages". The computation is usually distributed spatially, e.g. each processor holds part of the data locally, and communicates with its spatial neighbours. Conceptually simple, yet often suffers load-balancing (efficiency) and surface-to-volume ratio (scaling) problems. Simple way to parallelize initially serial loops that do not have strong internal dependencies. No free lunch: Results are usually terrible due to branch-and-bound, e.g. essentially serial code interspersed with parallel parts. Biggest problem is memory contention, e.g. two threads updating the same variable simultaneously, which is solved using atomic instructions and/or critical sections, which further deteriorate performance. Computations are broken-down into individual tasks with dependencies and conflicts. Threads execute asynchronously, picking up free tasks as they become available, i.e. we get implicit load-balancing for free. If dependencies and conflicts are specified correctly, we don't have to worry about concurrency problems or memory contention in each task. Usually requires a complete re-design of the underlying algorithms.
Full transcript