280 likes | 421 Views
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. Goals. Flexible, Flexible, Flexible Should be fluid enough to modify and extend Efficiency
E N D
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.
Goals • Flexible, Flexible, Flexible • Should be fluid enough to modify and extend • Efficiency • Secure and reliable • Look for available components
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
Deliverables • Design classes – with all details • Design subsystems – with all details • Interfaces • Use-case realization design • Deployment diagram
Flexibility • Model-View-Controller Architecture • UI • Application • Database • Three separate pieces that are developed independently • Interfaced with each other
Design considerations • Concurrency issues • Language issues • Administrative issues • Procedures • Versioning • Permissions and security • Responsibilities • Documentation • Schedules and testing
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
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
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
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!!
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
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
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
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?
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
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?
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
Use-case design • Detail the steps of use-case – sequence diagram. Fig 18.2,3,4 • Refine activity diagrams • Develop state charts
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
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
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
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
Implementation • Implement class • Implement subsystem • Perform unit testing
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
Database access • Issues pertaining to distributed system • Synchronization • Replication • Failure handling • Transaction processing • Persistence • Security • Resource Pooling • User Interface
Deployment • Map of software architecture to hardware architecture • Type and possible deployments • Nodes, relationships and component on nodes
Objectives of Design • Streamline Implementation • Faster delivery • Standardized product • Cheaper • Components • Patterns • Framework
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