1 / 73

CSC450 Software Engineering

Devon M. Simmonds University of North Carolina, Wilmington. Software Design . CSC450 Software Engineering. Slides adapted from Robert B. France and other sources. Software Design – bridging the gap between requirements & Implementation. In this lecture we will address:

sadah
Télécharger la présentation

CSC450 Software Engineering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Devon M. Simmonds University of North Carolina, Wilmington Software Design CSC450Software Engineering Slides adapted from Robert B. France and other sources.

  2. Software Design– bridging the gap between requirements & Implementation • In this lecture we will address: • An introduction to software design • Software design phases • Software design principles • UML package diagrams • UML component/deployment diagrams Software Design Requirements Analysis Implementation Systems Engineering Testing Deployment Evolution

  3. What is Software Design? • Software design expresses a solution to a problem in programming language independent terms. • This permits a design to be implemented in any programming language.

  4. Why do we design? • A key design challenge is controlling complexity

  5. Controlling Complexity • Complexity handling mechanisms: • Modularization - breaking up a solution into logical units. • Abstraction - use functional and data abstraction.

  6. Design Principles • Separation of concerns • Modularity • Abstraction • Generality • Incrementality • Anticipation of change

  7. Moving from problem to solution Requirements Spec Design Spec System attributes, anticipated changes, design constraints Design goals Use Cases Contracts • Architecture • subsystem structure • subsystem interfaces • etc. Class Diagrams Other models

  8. Requirements versus Design Class Diagrams • Domain analysis: Exploratory domain models are class diagrams in which classes represent domain concepts. • Classes in these diagrams DO NOT represent software concepts. • Requirements specification: A requirements class model (system domain model) consists of class diagrams in which the classes represent information that will be maintained by the software. • Design specification: A design class model (system model) consists of class diagrams in which classes represent solution concepts.

  9. An Example of a Requirements Class Diagram

  10. An example of a design class diagram EmployeeRole + getName [e2] crewMember * * * * * * * Airplane Booking SpecificFlight 0..1 * * * * * * * addLinkToSpecificFlight [a2, d3] Booking [c2] + specifyAirplane [a1] deleteLinkToSpecificFlight [d2] + createFlightLog [b1] * + changeAirplane [d1] + findCrewMember [e1] FlightLog 0..1 addLinkToBooking [c3] PassengerRole FlightLog [b2] + makeBooking [c1] addLinkToBooking [c4]

  11. Design phases • Architectural Design • Identify subsystems and the services they provide • Describe interactions across subsystems • Subsystem Design: • Define classes • Describe how objects interact to accomplish subsystem services • Sequence diagrams, state machines, etc. • User Interface Design • Data structures/Database Design • Algorithm Design • Pre and post conditions • Test Case Design

  12. UML Diagram Types for Design • Architectural Design • Package diagrams • Component diagrams • Deployment diagrams • Subsystem Design: • Class diagrams • Sequence diagrams • State machines • Object Constraint language • To express constraints on models and model elements

  13. Outline • An introduction to software design • Software design phases • Software design principles • UML package diagrams Software Design Requirements Analysis Implementation Systems Engineering Testing Deployment Evolution Software Design – bridging the gap between requirements & Implementation

  14. UML Packages Name in “box” Name in tab Use of membership symbol Client Shape Point Domain Production Fill Order Ship Order Order Processing Sales • A package is rendered as a tabbed folder • A package is a collection of model elements • A package owns its model elements • destruction of the package results in destruction of the model elements • relationship between a model element and its package is a composition 14

  15. Packages as a namespace +Client Domain Production Fill Order Ship Order OrderProcessing Sales • A package defines a namespace • A model element belongs to at most one package • Model elements can be referenced outside of the packages they are defined in, package1::class1::etc. • Domain::OrderProcessing::Fill • These are examples of qualified names. • A package can contain other packages • Domain::Production • Package elements may have public or private visibility only. 15

  16. Example: package with sub-packages 16

  17. Details of Payments Package Domain::Payments::Payment

  18. Packages of a Business System Customer Care Order Processing Accounts Receivable Marketing Package can have dependencies on other packages

  19. A grouping of model elements. Name A dependency indicating that the public contents of the target package are added to the namespace of the source package. A dependency indicating that the public contents of the target package are added to the namespace of the source package. «import» «merge» A dependency indicating that the public contents of the target package are available in the namespace of the source package. «access» UML packages - core concepts Construct Description Syntax Package Import Access Merge

  20. Package Import, package access and package merge

  21. Packages of a Business System- with specific dependencies Customer Care Order Processing Marketing +A <<access>> <<import>> +A -A -B cut() paste() copy() paste()

  22. Package Merge Order Processing Accounts Receivable Marketing <<merge>> <<merge>>

  23. Package Merge (2)

  24. Introduction to UML Component Diagrams

  25. Component definitions • Szyperski: • A software component is a binary units of independent production, acquisition and deployment that interact to form a functioning system • A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third-parties. • Councill and Heinmann: • A software component is a software element that conforms to a component model and can be independently deployed and composed without modification according to a composition standard.

  26. COMPONENT NOTATION • A component is shown as a rectangle • Labelled with a stereotype <<component>> • Optionally, in the right hand corner a component icon can be displayed • A component icon is a rectangle with two smaller rectangles jutting out from the left-hand side • This symbol is a visual stereotype

  27. Component ELEMENTS • A component can have • Interfaces An interface represents a declaration of a set of operations and obligations • Usage dependencies A usage dependency is relationship which one element requires another element for its full implementation • Ports Port represents an interaction point between a component and its environment • Connectors • Connect two components • Connect the external contract of a component to the internal structure

  28. INTERFACE • May be shown using a rectangle symbol with a keyword <<interface>> preceding the name • For displaying the full signature, the interface rectangle can be expanded to show details • Can be • Provided • Required

  29. INTERFACE • A provided interface • Characterize services that the component offers to its environment • Is modeled using a ball, labelled with the name, attached by a solid line to the component • A required interface • Characterize services that the component expects from its environment • Is modeled using a socket, labelled with the name, attached by a solid line to the component • In UML 1.x were modeled using a dashed arrow

  30. INTERFACE • Where two components/classes provide and require the same interface, these two notations may be combined • The ball-and-socket notation hint at that interface in question serves to mediate interactions between the two components • If an interface is shown using the rectangle symbol, we can use an alternative notation, using dependency arrows

  31. DEPENDENCIES • Components can be connected by usage dependencies • Usage Dependency • A usage dependency is relationship which one element requires another element for its full implementation • Is a dependency in which the client requires the presence of the supplier • Is shown as dashed arrow with a <<use>> keyword • The arrowhead point from the dependent component to the one of which it is dependent

  32. PORT • Specifies a distinct interaction point • Between that component and its environment • Between that component and its internal parts • Is shown as a small square symbol • Ports can be named, and the name is placed near the square symbol • Is associated with the interfaces that specify the nature of the interactions that may occur over a port

  33. PORT • Ports can support unidirectional communication or bi-directional communication • If there are multiple interfaces associated with a port, these interfaces may be listed with the interface icon, separated by a commas

  34. PORT • All interactions of a component with its environment are achieved through a port • The internals are fully isolated from the environment • This allows such a component to be used in any context that satisfies the constraints specified by its ports • Ports are not defined in UML 1.x

  35. An external view (or black box view) shows publicly visible properties and operations EXTERNAL VIEW • A component have an external view and an internal view • An external view of a component is by means of interface symbols sticking out of the component box • The interface can be listed in the compartment of a component box

  36. INTERNAL VIEW • An internal, or white box view of a component is where the realizing classes/components are nested within the component shape • Realization is a relationship between two set of model elements • One represents a specification • The other represent an implementation of the latter

  37. INTERNAL VIEW • The internal class that realize the behavior of a component may be displayed in an additional compartment • Compartments can also be used to display parts, connectors or implementation artifacts • An artifact is the specification of a phisycal piece of information

  38. INTERNAL VIEW • Components can be built recursively

  39. Component Diagram Exercise Component Diagrams Exercise • Create a component diagram using the problem description below. The BirdCage Corporation needs software to aid the management of its business. The corporation builds its business around domestic birds. BirdCage arranges its business around different services with each service being managed by a different company making BirdCage a group of companies. Companies are divided into departments. Services include veterinary services, safekeeping of birds, bird calisthenics and a bird competitions service. In order to streamline its business, BirdCage classifies the veterinary and safekeeping services as medical services. The other two services are regarded as entertainment services. In the future the company hopes to add a number of “Nutritional” services to address the production and sales of food for birds. The corporation classifies birds as either exotic or non-exotic. BirdCage does not provide entertainment services for exotic birds. Owls and crows are non-exotic birds, while macaws, cockatoos and green quakers are exotic. BirdCage seeks to maintain a minimum stock of at least 10 of each type of exotic bird.

  40. Introduction to UML Deployment Diagrams

  41. DEPLOYMENT DIAGRAMS • Deployment diagrams • Show the physical relationship between hardware and software in a system • Hardware elements: • Computers (clients, servers) • Embedded processors • Devices (sensors, peripherals) • Are used to show the nodes where software components reside in the run-time system • There is a strong link between components diagrams and deployment diagrams

  42. DEPLOYMENT DIAGRAMS • Deployment diagram • Contains nodes and connections • A node usually represent a piece of hardware in the system • A connection depicts the communication path used by the hardware to communicate • Usually indicates the method such as TCP/IP

  43. DEPLOYMENT DIAGRAMS • Deployment diagrams contain artifact • An artifact • Is the specification of a phisycal piece of information • Ex: source files, binary executable files, table in a database system,…. • An artifact defined by the user represents a concrete element in the physical world

  44. DEPLOYMENT DIAGRAMS • An artifact manifest one or more model elements • A <<manifestation>> is the concrete physical of one or more model elements by an artifact • This model element often is a component • A manifestation is notated as a dashed line with an openarrow-head labeled with the keyword <<manifest>>

  45. DEPLOYMENT DIAGRAMS

  46. Cohesion & Coupling

  47. Cohesion Cohesion: The degree of interaction (dependency) within a module • Degree of cohesion can range from coincidental cohesion (worst case) to Functional or Informational cohesion (best case). 47

  48. Coincidental Cohesion • Module performs multiple, unrelated actions. • Module M carries out the following sequence of actions: • read in rainfall • calculate average • read in temperatures • output temperatures • Problems • Difficult to maintain • Cannot reuse • Difficult to understand 48

  49. Logical Cohesion • Module performs a set of related actions, one of which is selected by the client. • Going on a journey • GO BY CAR • GO BY TRAIN • GO BY BOAT • GO BY PLANE 49

  50. Logical Cohesion • A “grab bag” from which client selects one feature. • Module that performs all I/O; • code for all I/O; code for input only; code for output only; code for disk I/O; code for tape I/O; code for keyboard input; … • Problems • Difficult to understand interface • Difficult to maintain • Difficult to reuse 50

More Related