1 / 12

A case study on making the transition from functional to fine-grained decomposition

A case study on making the transition from functional to fine-grained decomposition. Constantinos Constantinides Birkbeck, University of London. Motivation. In order to produce a tangled-free implementation, design artifacts must explicitly address crosscutting concerns.

theodore-pallas
Download Presentation

A case study on making the transition from functional to fine-grained decomposition

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. A case study on making the transition from functional to fine-grained decomposition Constantinos Constantinides Birkbeck, University of London

  2. Motivation • In order to produce a tangled-free implementation, design artifacts must explicitly address crosscutting concerns. • How to adapt established OOA/D techniques to an AO context.

  3. Motivation (cont.) • To consider “early aspects”, and model them from early stages of development. • Fine-grained decomposition implies no dominance of components over aspects. • Capture of crosscutting concerns in code should be the natural consequence of fine-grained modularity.

  4. Case study: Implementing a news service Client is authenticated. Server has not reached its maximum allowable number of clients logged in. No other client is currently posting news. No other client is currently waiting to post news. Multiple clients may concurrently read news. NewsService Read News Search News Client (reader) Client is authenticated. Server has not reached its maximum allowable number of clients logged in. No other client is currently reading news. No other client is currently posting news. No other client is currently waiting to post news. Post News Delete News Client (writer)

  5. UML domain model NewsItem 1 NewsDatabase * catalogs category 1 1..* contained-in * Session 1 * posts 1 houses logs-completed initiated-by writer 1 * posts-news-on Client * NewsServer writer reads-news-from * reader Authentication Synchronization Scheduling

  6. System Sequence Diagram for use case Post News :Client :NewsService [(client is logged on) && (server has not reached maximum capacity)] PostNews() System Operations PostNews() addNewsItem(item) endPostNews() [(no active writers && no active readers) && (no waiting writers)] addNewsItem(item) confirmation, notify waiting clients update synchronization counters *[more items] endPostNews() update authentication counters confirmation for completion of service

  7. Operation Contract for addNewsItem(item)

  8. Interaction diagram for addNewsItem() (no active writers && no active readers); if (waiting writers > 0) (decrement waiting writers); increment active writers; 1: precondition(addNewsItem) :Synchronization 5: postaction(addNewsItem) decrement active writers addNewsItem(item) 3: makeEntry(item) :NewsDatabase :NewsServerController no waiting writers • if (waiting writers > 0) • (notify waiting writers) • else • notify waiting readers; 2: precondition(addNewsItem) :Scheduling 4: postaction(addNewsItem)

  9. Class diagram NewsDatabase 1 NewsItem catalogs * makeEntry() category 1 1 1..* contained-in * Session * houses posts 1 logs-completed writer 1 * posts-news-on Client * NewsServer writer addNewsItem() deleteNewsItem() viewNewsItem() reads-news-from * reader <<interface>> AspectIF Authentication precondition() postaction() Synchronization Scheduling

  10. Iteration 2: Introducing Observer semantics posts-news-on * NewsServer Client <<interface>> SubjectIF writer monitors-news-from * attachObserrver() detachObserver() sendNotification() reader <<interface>> ObserverIF update() • abstract aspect ObserverProtocol { • abstract pointcut stateChanges(SubjectIF s); • … • // implementation of methods of SubjectIF, • // ObserverIF • } ObserverProtocol abstract aspect ObserverProtocol { declare parents: NewsServer implements SubjectIF; declare parents: Client implements ObserverIF; pointcut stateChanges(SubjectIF s): …; …} ConcreteObserverProtocol

  11. Some observations • Crosscutting may first appear in use cases. • It can propagate throughout analysis and design artifacts. • We can treat aspects as conceptual classes in domain model, and as first-class abstractions in design artifacts (interaction and class diagram). • Certain aspects can be defined by before and after behavior. • Can precondition/postaction lead to Design By Contract?

  12. Conclusion • Fine-grained decomposition and explicit capture of crosscutting concerns can aid in tracing requirements to code. • Facilitation of crosscutting concerns as first-class abstractions allows for a higher level of reuse and adaptability.

More Related