Download Advanced Software Paradigms: Requirements and Object Representation - Prof. Abdelghani Bel and more Study notes Computer Science in PDF only on Docsity!
Domain-specific Software Architectures
- Objectives
- Definitions...................................................................
- DSSA Methodology....................................................
- DSSA main components
- 4.1. Domain model
- 4.2. Reference Requirements........................................
- 4.3. The reference architecture
- domain............................................................................... 5. Case Study [Gary A. Curry et al.]: A Graphical Editor
- 5.1. Reference Requirements for the Domain
- 5.1.1. Stable Functional Requirements:.................
- 5.1.2. Variable Functional Requirements
- 5.2. Reference Architecture
- 5.2.1. Reference Structure Chart
- 5.2.2. Stable Modules
- 5.2.3. Variable Modules
- 5.2.4. Reference Class Model................................
- Summary:..................................................................
1. Objectives - Engineers often draw annotated diagrams of components and the relationships between them to describe the high-level design or architecture of a system. We seek to make this intuitive notion of an architecture more rigorous by defining precise meanings and notations for such specifications. - Reuse of source modules alone cannot achieve dramatic reductions in cost and schedule, since coding and unit testing typically account for only 10-20% of the overall software life cycle effort. - Architecture-based analysis coupled with rigorously defined module interface conventions can lead to significant reductions in defects and reductions in risk and in the overall life cycle costs can by a factor of 3 to 10.
- Given a generic framework or architecture, developing systems within the domain can be accomplished more efficiently because many components will be reusable and the interfaces will be well-defined when new components must be developed. 4. DSSA main components
- Domain model
- Reference requirements
- Stable requirements
- Variable Requirements
- Reference architecture
4.1. Domain model
- The domain analysis is the initial step in Domain- Specific Software Architecture, and the analysis of the domain ordinarily consists of input from customers and "domain experts.
- Domain experts are usually familiar with previous systems of this type or other aspects of the domain of interest. They may specialize in a specific area of the domain, or may have actually help develop a similar problem domain or related applications under such a domain.
- The customers add their own requirements for the domain and make modifications based on their needs and interests.
- The customer considers their needs statement as requirements , however, the functional requirements define the problem domain, and the design and implementation requirements constrain the architecture.
- The domain model is referenced by developers and other professionals that perform maintenance on specific applications in a domain, and the domain model should provide them with an understanding of the domain aspects.
- It uses the domain dictionary, which is the text reference source for words and phrases found in scenarios and the customer’s needs statement, and the context (block) diagram graphically represents
4.2. Reference Requirements
9 Functional requirements, 9 Non-functional requirements, 9 Design requirements, and 9 Implementation requirements.
- The functional requirements are the essential operations/processes, their numbers, etc.
- The non-functional requirements represent all other functionality of the domain, i.e., security, extendibility, etc.
- The design requirements focus upon the architectural style and the user interface style:
9 The architectural style will affect the performance, development cost, and the interfacing style of the corresponding components of the system. 9 The user interface style can be divided into three broad categories: command- line, menu driven, pull-down menu driven user, and web-based interfaces.
- The implementation requirements deal with the determination of the programming language, operating system, hardware platform, and networking capabilities when applicable.
9 Constraints are the ranges of parameter values, relationships, and component attributes. 9 The rationale is the retrospective "lessons learned" based upon using the reference architecture in development of applications. Constraints are the system guidelines.
5. Case Study [Gary A. Curry et al.]: A Graphical Editor domain. - The graphical editor provides the user an interface to manipulate shapes, lines, and text in order to graphically represent objects, data, and relationships between them. - The graphical editor domain includes the ability to create Data Flow Diagrams (DFD), structure charts, Entity/Relationship (ER) diagrams, state transition diagrams, as well as, numerous other types of design and architecture graphical modeling documents. - The user needs to be able to show relationships and behavior by drawing multiple line types and arrows to connect these objects, and the editor must be able to support the insertion of text onto objects and corresponding lines to describe their functionality. - The user should be able to create, delete, and move the lines in the document, and the ability to save or open a file is vital. - Also, it is necessary to provide the option to output to a printer. - In a more advanced version of a graphical editor, the support of color coding objects and lines should be available; further, the ability to create custom objects and relationships to better describe the user’s information modeling. - Some versions may also support the option of animation to show flow, and thus, improve the understanding of the objects. - The editor should be able to handle image types of various formats such as PICT, RTF, SYLK, MIF, JPEG, GIF, BMP, TIF, and ICN to allow distinct products to interact by data interchange.
5.1. Reference Requirements for the Domain
- The goal is to specify the scope of the domain. It contains a list and description of functional requirements for the domain. The following is a refined preliminary report.
9 selector arrow - select a graphical object on screen; targets object for application action 9 ruler - displays a ruler on the screen xy borders; vertical and horizontal measurements 9 inches - displays the dimensions on ruler in inches 9 centimeters - displays the dimensions on the ruler in centimeter 9 background grid - background of user screen is of grid type such as xy plane; allows for more precise depiction of images 9 grid spacing - provides a method of changing the background grid spacing 9 snap to grid - locks image onto background grid system as a graphical object is dragged across the screen 9 grid lines – indicates the vertical and horizontal background grid with dotted lines 9 grid minor dots – indicates incremental positions between grid lines
5.1.2. Variable Functional Requirements
- Unlike stable requirements, variable functional requirements may change from application to application.
- They represent the additional and supplemental functionality of the system domain. Such functionality adds to the user-friendliness and overall applicability of the system.
- The requirements are: 9 square image - draws a square on grid system; object representation 9 circle image - draws a circle on grid system; object representation
9 triangle image - draws a triangle on grid system; object representation 9 line image - draws a line on the grid system; object representation 9 line arrow image - direct function call; shows image referencing on screen 9 dash arrow image - asynchronous call; dashed arrow image 9 parameter arrow image - smaller and shorter arrow image used to show direction of parameter being passed between graphical objects 9 sticky arrow - arrows connecting graphical objects will reposition themselves in accordance with object location as objects are edited 9 filled parameter arrow image - used to represent data couple 9 unfilled parameter arrow image - used to represent control couple 9 various arrow head(s) - variations on the type of pointers on the arrow 9 sharpen - sharpen the quality of the image 9 smooth - smooth the image 9 rotate - rotate the image; clockwise or counterclockwise 9 invert - invert the image; flip 180 degrees 9 RGB controls - three slider bars for controlling the color scheme 9 mirror - mirror the image 9 left-right justify - justify the image according to margins 9 various baseline symbols - used to show such properties as aggregation and inheritance 9 iterative function - recursive type graphical object(square with arrow returning to itself) 9 module - graphical object with double borders to denote a module, possible complex 9 data store - graphical object used to represent a type of data store 9 external entity - graphical representation of an external person, place, or thing
Subchart A:
Subchart B:
Subchart C:
Subchart D:
5.2.2. Stable Modules
- Stable modules will appear in all applications within the graphical editor domain.
- These modules are: 9 file subsystem - controls all user requests of file menu options by calling the appropriate file module to fulfill the request. 9 file open – provides a file open dialog box for the user to make a selection from, and processes the selection to open the requested file. 9 file close – closes the currently opened file if there are no unsaved changes, otherwise prompts the user to save the changes prior to closing. 9 file new - creates and opens a new file, possibly providing options to the user of the types of templates available within the specific application based upon variable requirements. 9 file save - saves the unsaved changes of the currently open file. 9 file save as – provides a dialog box to prompt the user with the name to save the currently open file. 9 file print – prompts the user with the current printer configuration and spools the currently file to a printer device. 9 file exit - checks for any unsaved changes in currently open files, and, if there are any, prompts the user to save the changes before exiting the program. 9 edit subsystem - controls all user requests of edit menu options by calling the appropriate edit module to fulfill the request. 9 edit undo - undoes the last action(s) within the undo buffer. 9 edit cut - cuts the selected object(s) to the clipboard buffer. 9 edit copy - copies the selected object(s) to the clipboard buffer. 9 edit paste - pastes the selected object(s) from the clipboard buffer. 9 edit text – provides a text cursor within the selected text object, allowing the user to insert, delete, modify text.
9 edit image subsystem – controls all user requests of edit image options by calling the appropriate edit image module to fulfill the request. 9 edit image - provides "handles" on the selected image object, allowing the user to insert, delete, modify the image 9 edit arrow subsystem - controls all user requests of edit arrow options by calling the appropriate edit arrow module to fulfill the request. 9 interface subsystem – controls all user requests to change the current interface by calling the appropriate interface module to fulfill the request. 9 selector arrow - provides a method for graphical object on screen allowing the user to select objects for application action. 9 ruler - displays a ruler on the screen xy borders, providing a visual interface of vertical and horizontal measurements. 9 inches – a method to display the dimensions on ruler in inches. 9 centimeters – a method to display the dimensions on the ruler in centimeter. 9 background grid - provides a background of grid type such as xy plane of user screen is, allowing for precision placement of objects. 9 grid spacing - provides a method of changing the background grid spacing 9 snap to grid – a method which locks the image onto background grid system as a graphical object is repositioned on the screen, providing the freeing the user from having to pay close attention to the vertically or horizontal alignment of objects. 9 grid lines – draws the current background grid with dotted lines at each horizontal and vertical gridline. 9 grid minor dots – draws vertical and horizontal lines of dots on the screen to indicate incremental positions between grid lines.
