1 / 8

Software Architecture

Software Architecture. overview. Architectural views.

kaipo
Télécharger la présentation

Software Architecture

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. Software Architecture overview

  2. Architectural views • Views are aspects or dimensions of an architectural model. According to the IEEE 1471 (IEEE, 2000), a view is a "representation of a whole system from the perspective of a related set of concerns." A view can contain one or more models. Some common architectural views are: • Objectives/purpose. Describes what is needed. • Behavior/function. Describes what the system does. • Information/data. Describes the information created by and retained in the system. • Form/structure. Describes the physical structure of the software (for example, modules and components). • Performance. Describes how effectively the system performs its functions.

  3. Views: Objectives/Purpose • One of the roles of the architect is to help the client identify the system's objectives and priorities. Functional objectives can be specified with precision, but objectives such as maintainability are harder to define. The architect must prepare models to help the client to clarify abstract objectives. • One of the most common models in this category is “use case model”

  4. Views: Behavioral/Functional • Functional or behavioral models specify what the system does. These models are a response to the functional objectives in the objectives models. • The importance of behavioral models increases as systems become more complex and as their behavior becomes less evident from the system's form. • The architect must determine the level of detail needed in the behavioral model. • Too little detail and the client may not understand the behavior being provided or the developers may implement the wrong functionality. • Too much detail and the models may become incomprehensible and difficult to maintain during the design life cycle.

  5. Views: Behavioral/Functional • In modern software development, we usually only start with a partially specified behavior model because we usually do not have a complete set of fully defined requirements and objectives before design begins. • Each iteration of design allows the users and acquirers to refine their requirements and for the models to be refined, respectively. • There are several kinds of behavioral models: • User interface prototypes • Scenarios and threads • State transition diagrams • Process models

  6. Views: Information/Data • In this view, the data that is created and retained by an application and the relationships among that data are represented. It is not uncommon for the data model to be the most complex aspect of a system. • Models: • Entity Relationship Model • UML class diagram

  7. Views: Form/Structure • Models of form represent the structure of the system. • In simple systems, the structure could be inferred from its function and the behavioral and information models were sufficient to specify the architecture. Today, with more systems being distributed and utilizing commercial technologies, the structure can no longer be simply inferred from the functional model. • Scale models • Components and Connectors • Source Code

  8. References • IEEE 2000. "IEEE Recommended Practice for Architectural Descriptions of Software Intensive Systems." IEEE Std 1471-2000. New York, NY: Institute of Electrical and Electronics Engineers.

More Related