What must software engineering designers do if they do not have a complete, corr

Question

What must software engineering designers do if they do not have a complete, correct, and consistent product design when beginning their work? What can software designers do to check that a use ease diagram contains all the use cases that it should? Explain how the Layered style supports reuse. Carefully explain visibility and accessibility of program entities in regard to Information Hiding Heuristics. What are the two main techniques for evaluating architectural design alternatives? Carefully explain them.

Explanation / Answer

1. When the software development team works on any project, then there are many things to be considered. The team holds discussions with various stakeholders from problem domain and tries to bring out as much information as possible on their requirements. The requirements are contemplated and segregated into user requirements, system requirements and functional requirements. The requirements are collected using a number of practices as given -

2. There are various things which a software designers considers while creating a product design by evaluating the use case diagrams.Use case diagrams show business use cases, actors, and the relationships between them. The relationships between actors and business use cases state that an actor can use a certain functionality of the business system.

Organizations that use the use cases requirements approach insert the use cases into an SRS document in place of the functional requirements. This is called a use case-based software requirements specification. Although some requirements engineers view use cases as requirements, others caution that use cases are not requirements. They feel instead that an SRS should contain formal statements of requirements that can be used as the conditions of system acceptance, the use cases can be added to the SRS if desired as an add-on.

3.Layered architecture focuses on the grouping of related functionality within an application into distinct layers that are stacked vertically on top of each other. Functionality within each layer is related by a common role or responsibility. Communication between layers is explicit and loosely coupled. Layering your application appropriately helps to support a strong separation of concerns that, in turn, supports flexibility and maintainability.

The layered architectural style has been described as an inverted pyramid of reuse where each layer aggregates the responsibilities and abstractions of the layer directly beneath it. With strict layering, components in one layer can interact only with components in the same layer or with components from the layer directly below it. More relaxed layering allows components in a layer to interact with components in the same layer or with components in any lower layer.

Common principles for designs that use the layered architectural style include:

4. Visibility of programs:

A program entity is visible at a point in a program text if it can be referred to by name at that point; the portion of a text over which an entity is visible is its visibility.

Types of Visibility:

Local—Visible only within the module where it is defined

Non-local—Visible outside the module where it is defined, but not visible everywhere in a program

Global—Visible everywhere in  a program

An entity is exported from the module where it is defined if it is visible outside that module.

Object-Oriented Feature Visibility:

Private—Visible only within the class where it is defined a type of local visibility.

Package—Visible in the class where it is defined as well as classes in the same package or namespace :

Protected—Visible in the class where it is defined and all sub-classes.

Public—Visible anywhere the class is visible.

Accessibility:

A program entity is accessible at a point in a program text if it can be used at that point. A program entity is accessible wherever it is visible. A program entity may also be accessible where it is not visible.

5.The decision making technique describes a systematic way of choosing an alternative among a finite number of given ones. It encompasses several activities such as in this paper we focus on four specific activities, quality attribute description, quality attribute importance determination, fulfillment description, and uncertainty description. These activities are enacted in every available decision-making technique. A mechanism concerns, and eventually prescribes, a specific way for enacting an activity, i.e., it is the how of that activity. Therefore, since decision-making techniques share the same four activities, their differences come from the ways they enact these activities, i.e., from their mechanisms. We call a characterization schema a structure of activities and the related mechanisms, which can differentiate every available decision-making technique. From the point of view of an architect, a decision-making technique is one point in a fourdimensional space, one dimension per activity, from this perspective, a decision-making technique can be seen as a tuple of four mechanisms, one for each activity.

Related Questions

Navigate

• Browse (All)
• Browse W
• Subjects

---

---

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.