1 / 28

Flexible Design for Efficient and Secure Functionality

This design builds a logical model that delivers functionality, specifying implementation details and considering efficiency and security. It emphasizes flexibility and compatibility with available components.

salvadorlane
Download Presentation

Flexible Design for Efficient and Secure Functionality

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. Design Analysis builds a logical model that delivers the functionality. Design fully specifies how this functionality will be delivered. Design looks from the implementation point of view.

  2. Goals • Flexible, Flexible, Flexible • Should be fluid enough to modify and extend • Efficiency • Secure and reliable • Look for available components

  3. Each package becomes a subsystem • Details for interfaces is emphasized • For small systems you may take the analysis model and convert it into the design model • For large complex systems maintain two models • Ensure that these two models are consistent with each other

  4. Deliverables • Design classes – with all details • Design subsystems – with all details • Interfaces • Use-case realization design • Deployment diagram

  5. Flexibility • Model-View-Controller Architecture • UI • Application • Database • Three separate pieces that are developed independently • Interfaced with each other

  6. Design considerations • Concurrency issues • Language issues • Administrative issues • Procedures • Versioning • Permissions and security • Responsibilities • Documentation • Schedules and testing

  7. Design classes • Ready to be implemented classes • Interface and implementation • Detailed and Refined analysis classes • Implementation required classes • All attributes and operations are to be specified • Figure 15.2 • Completeness and sufficiency for users of the class

  8. High cohesion and low coupling • Use inheritance with care • In analysis inheritance is used only when an “is-a” relationship exists between analysis classes • In design you may use inheritance for the sake of code re-use • Inheritance is the strongest form of coupling and most inflexible • Template classes (general-purpose classes) that can be parameterized at runtime may be used

  9. Relationship - design • Refining associations into aggregation or composition • Implementing all forms of associations (1-1, 1-n, n-n) • Aggregation and composition implements 1-1 and 1-n and n-1 • Issues with reflexive association • Implementing association classes Clarifying all of this is refining analysis relationship into design relationship

  10. Associations can have properties – particularly when multiplicity is allowed • This clarifies cases of every instance of association • Composition, Aggregation, Collection • When to use collection? • Many to Many association needs to be reified – concretized • Bidirectional associations needs to reified to avoid cyclical ownership!!

  11. Analysis may have Association class!! • Simple association constraints since it depicts only one association for every instance of the object pair associated • Otherwise you need a separate class then inter-relate them appropriately • Navigation through a multiple association can be qualified using a qualifier (like member-id) as part of the association

  12. Sample Relationship • Manager manages one office • Supervisor may manage many projects • Supervisor’s time is broken-up over projects • A vendor works with many offices • An office uses many vendors • A project is assigned the necessary personnel

  13. Sample Relationship • Corporation has a head office and many other offices • Offices co-ordinate many projects and warehouses • Projects may have warehouses assigned • Projects may choose from one or another plant • Offices may be added or eliminated • Newer warehouses may be added

  14. Collection class • These specialize in managing collection of other objects • Essentially an ADT handler • Vector class is an example • Implements 1 to * • Reify for n-n or * - * – what does that mean?

  15. Interfaces • Interface defines a contract • Separates definition from implementation • Class defines an interface and an implementation • Interfaces do not carry any attributes and relationships • Derived classes gets the interface, attributes, and relationships from the parent class

  16. Interfaces contribute only contracted operations and can be used for plug-in components • Do not carry relationship • One may use pure abstract classes without relations – instead • Interfaces can become complex – why? • Interfaces have additional overhead – how?

  17. Figure 17.3, 17.4 shows the use of interface • Section 17.4 describes how to design using interfaces • Subsystems are designed to • Separate design concerns • Represent large grain component • Wrap legacy systems • Figure 17.10 • Adv. And dadv. of interfaces

  18. Use-case design • Detail the steps of use-case – sequence diagram. Fig 18.2,3,4 • Refine activity diagrams • Develop state charts

  19. State Chart • Similar to DFA • Defines states and transitions of one Reactive Object • Reactive objects respond to external events, clear lifecycle and state dependent behavior • Start node and potential end-node • Other nodes are intermediate well-defined states of the element • State transitions are triggered by system events • Events can be guarded • Transitions can also have actions • Figure 19.4, 19.5

  20. State Info • State name • Entry with action • Exit with action • Internal transitions and actions • Internal activity • Actions are atomic/uninterruptible • Activities may be interrupted by events

  21. Call event • Signal event • one way asynchronous communication • Change event • Boolean condition change • Time event • Absolute time • Elapsed time • There can be composite states - with decomposition indicators

  22. There can be concurrent composite states • Fork and/or join • Indicative of concurrency within the object • Can communicate between concurrent states using attributes • Sync states • Synchronization/communication between sub-machines • History of an object • Shallow and deep history • Fig. 20.3-11

  23. Implementation • Implement class • Implement subsystem • Perform unit testing

  24. Component • Physical replaceable part of a system • Each component may contain many classes and realize many interfaces • A class can be shown to be inside a component in 2 ways - fig 22.2 • Components usually are used to implement significant aspects of the system

  25. Database access • Issues pertaining to distributed system • Synchronization • Replication • Failure handling • Transaction processing • Persistence • Security • Resource Pooling • User Interface

  26. Deployment • Map of software architecture to hardware architecture • Type and possible deployments • Nodes, relationships and component on nodes

  27. Objectives of Design • Streamline Implementation • Faster delivery • Standardized product • Cheaper • Components • Patterns • Framework

  28. Topics for CASE tool • http://www.cs.queensu.ca/Software-Engineering/toolcat.html#label233 • http://www.rspa.com/spi/CASE.html • http://www.geocities.com/millermax2001/casetool.html • www.Ilogix.com • www.gentleware.com

More Related